http://www.exa.unicen.edu.ar/catedras/dwhouse/ diapositivas

http://www.tesis.ufm.edu.gt/

DATAWAREHOUSE

PREFACIO   

Desde que se inicia la era de la computadora, las organizaciones usan los datos desde los

sistemas operacionales para atender sus necesidades de información. Algunas proporcionan

acceso directo a la información contenida dentro de las aplicaciones operacionales. Otras, han

extraído los datos desde sus bases de datos operacionales para combinarlos de varias formas no

estructuradas, en su intento por atender a los usuarios en sus necesidades de información.

 

Ambos métodos han evolucionado a través del tiempo y ahora las organizaciones manejan

datos no limpios e inconsistentes, sobre los cuales, en la mayoría de las veces, se toman

decisiones importantes. La gestión administrativa reconoce que una manera de elevar su

eficiencia está en hacer el mejor uso de los recursos de información que ya existen dentro de la

organización. Sin embargo, a pesar de que esto se viene intentando desde hace muchos años, no

se tiene un uso efectivo de los mismos.

 

La razón principal es la manera en que han evolucionado las computadoras, basadas en

las tecnologías de información y sistemas. La mayoría de las organizaciones hacen lo posible por

conseguir buena información, pero el logro de ese objetivo depende fundamentalmente de su

arquitectura actual, tanto de hardware como de software.

 

El Data Warehouse, es actualmente, el centro de atención de las grandes instituciones,

porque provee un ambiente para que las organizaciones hagan un mejor uso de la información que

es administrada por diversas aplicaciones operacionales. Un Data Warehouse es una colección de

datos en la que se encuentra integrada la información de la Institución y que se usa como soporte

para el proceso de toma de decisiones gerenciales. Aunque diversas organizaciones y personas

individuales logran comprender el enfoque de un Warehouse, la experiencia ha demostrado que

existen muchas dificultades potenciales.

 

Reunir los elementos de datos apropiados desde diversas fuentes de aplicación en un

ambiente integral centralizado, simplifica el problema de acceso a la información y en

consecuencia, acelera el proceso de análisis, consultas y el menor tiempo de uso de la

información.

 

Las aplicaciones para soporte de decisiones basadas en un Data Warehouse, pueden

hacer más práctica y fácil la explotación de datos para una mayor eficacia del negocio, que no se

logra cuando se usan sólo los datos que provienen de las aplicaciones operacionales (que ayudan

en la operación de la empresa en sus operaciones cotidianas), en los que la información se obtiene

realizando procesos independientes y muchas veces complejos.

 

Un Data Warehouse se crea al extraer datos desde una o más bases de datos de

aplicaciones operacionales. Los datos extraídos son transformados para eliminar inconsistencias y

resumir si es necesario y luego, cargados en el Data Warehouse. El proceso de transformar, crear

el detalle de tiempo variante, resumir y combinar los extractos de datos, ayudan a crear el

ambiente para el acceso a la información institucional. Este nuevo enfoque ayuda a las personas

individuales, en todos los niveles de la empresa, a efectuar su toma de decisiones con más

responsabilidad.

 

La innovación de la tecnología de información dentro de un ambiente Data Warehouse,

puede permitir a cualquier organización hacer un uso más óptimo de los datos, como un

ingrediente clave para un proceso de toma de decisiones más efectivo. Las organizaciones tienen

que aprovechar sus recursos de información para crear la información de la operación del negocio,

pero deben considerarse las estrategias tecnológicas necesarias para la implementación de una

arquitectura completa de Data Warehouse.

1.1 1.1   Antecedentes históricos

 El concepto de Data Warehouse proviene de la combinación de dos necesidades que

generalmente no están asociadas, sin embargo son tomadas en conjunto para obtener un mejor

entendimiento del problema y presentar una posible solución. Estas necesidades son:

 

       Requerimiento del negocio, de una perspectiva amplia de la información de la

compañía.

       La necesidad del manejo de la información por parte del departamento de sistemas.

 

Tomándolas separadas, la demanda de los negocios requiere una vista amplia de la

información que pueda liderar soluciones basadas en permitir a cualquier usuario accesar cualquier

información sin importar donde esté ubicado. Sin embargo, éstas soluciones son simples, porque

ignoran fundamentalmente la distinción entre datos e información. De hecho, lo que los usuarios

del negocio requieren es información (algunas veces definida como datos, en el contexto de

negocios).

 

Debido a la forma en que las aplicaciones se encuentran y como continúan creciendo, éstas

no solamente contiene datos separados del contexto del negocio sino que algunas veces contienen

datos consistentes en todo el ámbito de la compañía. Entonces los datos son simplemente no

apropiados para el uso directo de usuarios finales.

 Sin embargo combinando las necesidades anteriormente mencionadas, se da una nueva

perspectiva. Si la necesidad del sistema de información de la administración de datos fuera tomada

en cuenta, la necesidad de los negocios de una consulta amplia de los datos de los negocios son

más fácil de reunir.

 

De igual manera la necesidad de obtener una consulta amplia de los datos y los obvios

beneficios del negocio que estos tienen, son la justificación requerida para resolver el problema de

administración de datos.

 A mitad de los años noventas el Data Warehouse se inició como una moda en la industria de

la computación, se ha anunciado el valor del concepto por más de una década, se puede ver este

desarrollo como una justificación, tal popularidad trae sus propios problemas. Uno de estos es que

en sus inicios, lleva a los vendedores a adaptar sus conceptos particulares para hacer una unión

entre éste y los productos que ellos venden. Debe recordarse que el Data Warehouse no puede ser

manejado por sí sólo. Este se inventó por las compañías para satisfacer sus propias necesidades,

éstas continuan existiendo y siguen creciendo de acuerdo al ambiente tecnológico en que los

negocios se operen y sean más complejos.

 Con el propósito de comprender la historia del Data Warehouse de una mejor manera, se

muestra la figura No. 1 (Antecedentes del Data Warehouse). Muchas de las claves del desarrollo de

computación son direccionadas a la evolución del Data Warehouse. Los aspectos históricos son

solamente aspectos generales, sin embargo, el progreso del desarrollo técnico y de negocios es

usado como un criterio en contra, el cual mide la situación actual en cualquier compañía o parte de

ella para entender como mejor proceda.

Figura No. 1  1.2 1.2        Aspectos teóricos

 Data Warehouse es el centro de la arquitectura para los sistemas de información en la

década de los noventas. Soporta el procesamiento informático al proveer una plataforma sólida, a

partir de los datos históricos para hacer el análisis. Facilita la integración de sistemas de aplicación

no integrados. Organiza y almacena los datos que se necesitan para el procesamiento analítico e

informático sobre una amplia perspectiva del tiempo.

 

Un Data Warehouse (o depósito de datos) es una colección de información orientado a

temas, integrado, no volátil, de tiempo variante, que se usa para el soporte del proceso de toma de

decisiones gerenciales. Se caracteriza, haciendo un contraste de los datos de un negocio

almacenados en él, a diferencia de los operacionales usados por las aplicaciones de producción. El

ingreso deestos en el Data Warehouse viene desde el ambiente operacional en casi todos los

casos. Este es un almacén de datos transformados y separados físicamente de la aplicación donde

se encuentran los mismos en el ambiente operacional.

 

1.3 1.3        Sistemas de información

Los sistemas de información se han dividido de acuerdo al siguiente esquema:  

  

       Sistemas Estratégicos:

Están orientados al apoyo en la toma de decisiones, facilitando la labor de la dirección

y proporcionando un soporte básico, para la toma de decisiones. Se caracterizan porque son

sistemas sin carga periódica de trabajo, es decir, su utilización no es predecible. Destacan

entre ellos: Los Sistemas de Información Gerencial (MIS), Sistemas de Información

Ejecutivos (EIS), Sistemas de Información Georeferencial (GIS), Sistemas de Simulación de

Negocios (BIS y que en la práctica son sistemas expertos o de Inteligencia Artificial - AI).

       Sistemas Tácticos:

Diseñados para soportar la coordinación de actividades y manejo de documentación,

definidos para facilitar consultas sobre información almacenada en el sistema y la gestión

independiente de la información por parte de los niveles intermedios de la organización.

Destacan entre ellos: los Sistemas Ofimáticos (OA), Sistemas de Transmisión de Mensajería

(E-mail y Fax Server), coordinación y control de tareas (Work Flow) y los sistemas de

tratamiento de documentos (Imagen, Trámite y Bases de Datos).

 

       Sistemas Técnico-Operativos:

Estos sistemas, cubren el núcleo de operaciones tradicionales de captura masiva de

datos y servicios básicos de tratamiento de los mismos, con tareas predefinidas

(contabilidad, facturación, almacén, presupuesto, personal y otros sistemas administrativos).

Estos, están evolucionando con la introducción de censores, autómatas, multimedia, bases

de datos relacionales más avanzadas y el Data Warehouse.

 

       Sistemas Interinstitucionales:

Este nivel de sistemas de información, es consecuencia del desarrollo organizacional

orientado a un mercado de carácter global, obliga a pensar e implementar estructuras de

comunicación más estrechas entre la organización y el mercado (Empresa Extendida,

Organización Inteligente e Integración Organizacional), todo esto a partir de la generalización

de las redes informáticas de alcance nacional y global (INTERNET), que se convierten en

vehículo de comunicación entre la organización y el mercado, no importa dónde esté la

organización (INTRANET), el mercado de la institución (EXTRANET) y el mercado (Red

Global).

 

Sin embargo, la tecnología Data Warehouse basa sus conceptos y diferencias entre

dos tipos fundamentales de sistemas de información en todas las organizaciones: los

sistemas técnico-operacionales y los sistemas de soporte de decisiones. Siendo este último

la base de un Data Warehouse.

 

1.3.1 1.3.1    Sistemas técnico-operacionales  

Son los que ayudan a manejar las empresas en sus operaciones cotidianas. Estos

operan sobre la columna vertebral de cualquier empresa o institución, entre las que se tiene

sistemas de ingreso de órdenes, inventario, fabricación, planilla y contabilidad, entre otros.

 

Debido a su volumen e importancia en la organización, los sistemas operacionales

siempre son las primeras partes de la empresa a ser computarizados. A través de los años,

estos sistemas operacionales se han extendido, revisado, mejorado y mantenido al punto

que hoy, son completamente integrados en la organización. Desde luego, la mayoría de las

más grandes de éstas en todo el mundo, actualmente no pueden operar sin sistemas

operacionales y los datos que estos sistemas mantienen.

 

1.3.2 1.3.2    Sistemas de Soporte de Decisiones  

Hay funciones dentro de las empresas que tienen que ver con el planeamiento,

previsión y administración de la organización. Estas funciones son críticas para la

supervivencia de las organizaciones, especialmente en nuestro mundo de rápidos cambios.

Las funciones como "planificación de marketing", "planeamiento de ingeniería" y "análisis

financiero", requieren de sistemas de información que los soporte. Pero estas funciones son

diferentes de las operacionales y los tipos de sistemas requeridos. Las funciones basadas en

el conocimiento son los sistemas de soporte de decisiones.

 

Estos sistemas están relacionados con el análisis de los datos y la toma de

decisiones, frecuentemente, son importantes para conocer cómo opera la empresa, ahora y

en el futuro. Estos, no sólo tienen un enfoque diferente al de los operacionales, sino tienen

un alcance diferente. Mientras las necesidades de los datos operacionales se orientan

normalmente hacia una sola área, los datos para el soporte de decisiones, con frecuencia,

toman un número de zonas diferentes y necesitan cantidades grandes de datos

operacionales relacionadas. Son estos sistemas sobre los cuales se basa la tecnología Data

Warehouse.

    

CAPITULO II 

1. 2.      CONCEPTOS GENERALES DE DATA WAREHOUSE   1.1. 2.1.               Definición 

En los ambientes de negocios competitivos de hoy, entender y administrar información es

crucial para las compañías, tomar decisiones a tiempo respondiendo a los cambios de los de

negocios. Las aplicaciones de procesamiento de datos han proliferado a través de una amplia

variedad de sistemas operativos en las ultimas dos décadas, complicando la tarea de localizar e

integrar datos para soporte de decisiones, tomando una decisión autoritaria se inicia la distribución

hacia todos los niveles de una organización. Más personas necesitan acceso a la información

necesaria para la toma de una decisión de negocios. Como resultado de manejar y usar ésta

competitivamente, muchas organizaciones hoy están construyendo Data Warehouse.

 

Data Warehouse soporta análisis de negocios y decisiones realizadas para la creación de

una base de datos integrada, consistente, orientada a temas e información histórica. Integra los

datos de múltiples sistemas heterogéneos a una base de datos consolidada. En la transformación

de éstos, permite a los administradores de negocios realizar análisis consistentes más sustantivos

y precisos.

 

Significativos beneficios en costos, tiempo y productividad, están asociados con el uso de

Data Warehouse en el procesamiento de información. Primero, los datos son accesados y

analizados fácilmente sin consumir tiempo, manipulando y procesando. Las decisiones son

realizadas con mayor rápidez y con la confidencialidad de que los datos son precisos.

La información integrada es mantenida en categorías que son significativas para producir

una operación. Las tendencias son analizadas y predecidas con disponibilidad de datos históricos.

Data Warehouse asegura que todos extraigan los mismos datos al mismo nivel, lo que elimina

resultados analíticos conflictivos y argumentos que no coincidan con la fuente y calidad de datos

usados en el análisis. En resumen, habilita información a procesar de una manera eficiente y

creíble. Un Data Warehouse:

  

       Es un almacén de datos en el que se recopila toda la información existente en una

empresa y se coloca en un sistema de administración de base de datos.

       Es un conjunto de herramientas de integración de información diseñado con el

propósito de facilitar la toma de decisiones.

Es una solución que permite examinar datos históricos y analizarlos en diferentes formas

tomando decisiones basadas en ellos. 

  1.2. 2.2.      Características   

       Orientado al tema

       Integrado

       De tiempo variante

       No volátil

 1.2.1. 2.2.1.           Orientado a temas

 Una primera característica del Data Warehouse es que la información se clasifica en

base a los aspectos que son de interés para la empresa. Siendo los datos tomados en

contraste con los clásicos procesos orientados a las aplicaciones.

En la Figura No. 2 se muestra el contraste entre los dos tipos de orientaciones.

 

Figura No. 2

 

El ambiente operacional se diseña alrededor de las aplicaciones y funciones tales

como préstamos, ahorros, tarjetas de crédito y depósitos para una institución financiera. Por

ejemplo, una aplicación de ingreso de órdenes puede acceder a los datos sobre clientes,

productos y cuentas. La base de datos combina estos elementos en una estructura que

acomoda las necesidades de la aplicación.

 

El ambiente Data Warehouse se organiza alrededor de sujetos tales como clientes,

vendedores, productos y actividades. Por ejemplo, para un fabricante, éstos son clientes,

productos, proveedores y vendedores. Para una universidad pueden ser estudiantes, clases

y profesores. Para un hospital pueden ser pacientes, personal médico, medicamentos.

Las aplicaciones están relacionadas con el diseño de la base de datos y del proceso.

El Data Warehouse enfoca el modelamiento de datos y el diseño de la base de datos. Las

diferencias entre la orientación de procesos y funciones de las aplicaciones y la orientación a

temas, radican en el contenido de los datos a nivel detallado. En el Data Warehouse se

excluye la información que no es usada por el proceso de sistemas de soporte de

decisiones, mientras que la información de las orientadas a las aplicaciones, contiene datos

para satisfacer de inmediato los requerimientos funcionales y de proceso, que pueden ser

usados o no por el analista de soporte de decisiones.

 

Otra diferencia importante está en la interrelación de la información. Los datos

operacionales mantienen una relación continua entre dos o más tablas basadas en una regla

comercial que está vigente. Las reglas del Data Warehouse miden el tiempo y las relaciones

encontradas entre sí. Muchas de las reglas comerciales (y sus correspondientes relaciones

de datos) se representan en el Data Warehouse, entre dos o más tablas.

 

En resumen, orientado a temas, significa que está organizado con relación a las

principales materias de la empresa. La orientación alrededor de los temas más importantes

de la corporación causa que el diseño del Data Warehouse es manejar datos. El manejo de

datos de las materias de la organización de éste, está en contraste con el proceso

clásico/funcional de las aplicaciones de la organización, el cual caracteriza los sistemas de

operación más antiguos.

 

El mundo del Data Warehouse está organizado en relación con las materias más

importantes de las áreas de la corporación, las que afectan el diseño e implementación en la

búsqueda de datos para el Data Warehouse. Otra distinción importante entre las

aplicaciones orientadas a datos operacionales y los contenidos en el Data Warehouse, es la

relación estos. Las aplicaciones operacionales se relacionan según las necesidades

inmediatas concernientes al negocio, lo que es exacto y relevante justo ahora. Una relación

en el ambiente operacional está basada en las reglas actuales del negocio, relación en

marcha entre dos o más tablas o bases de datos.

 1.2.2. 2.2.2.           Integrado

  

El aspecto más importante del ambiente Data Warehouse es que la información

encontrada al interior está integrada. Esta integración de datos se muestra de muchas

maneras: en convenciones de nombres consistentes, en la medida uniforme de variables, en

la codificación de estructuras, en atributos físicos de los datos, fuentes múltiples y otros. En

la Figura No. 3 de la página No. 16, se muestra el contraste de la integración encontrada en el

Data Warehouse con la carencia de integración del ambiente de aplicaciones, con sus

respectivas diferencias.

A través de los años, los diseñadores de las diferentes aplicaciones toman sus propias

decisiones sobre cómo se debería construir una aplicación. Los estilos y diseños

personalizados se muestran de varias maneras. Se diferencian en la codificación, en las

estructuras claves, en sus características físicas, en las convenciones de nombramiento y

otros. La Figura No. 3 mencionada, muestra algunas de las diferencias más importantes en

las formas en que se diseñan las aplicaciones.

 

       Codificación. Los diseñadores de aplicaciones codifican el campo GENERO en

varias formas. Estos, representan GENERO como una "M" y una "F", otros como un

"1" y un "0", otros como una "X" y una "Y" e inclusive, como "masculino" y "femenino".

No importa cómo el GENERO llega al Data Warehouse, probablemente "M" y "F" sean

tan buenas como cualquier otra representación. Lo importante es que el GENERO

debe llegar al Data Warehouse en un estado integrado uniforme. Por lo tanto, cuando

el GENERO se carga en el Data Warehouse desde una aplicación, donde ha sido

representado en formato "M" y "F", los datos deben convertirse al formato del Data

Warehouse que no precisamente debe ser el mismo.

 

       Medida de atributos. Los diseñadores de aplicaciones obtienen las unidades de

medida en una variedad de formas. Un diseñador almacena los datos en centímetros,

otros en pulgadas, otros en millones de pies cúbicos por segundo y otros en yardas. Al

dar medidas a los atributos, la transformación traduce las diversas unidades usadas en

las diferentes bases de datos para transformarlas en una estándar común. Cualquiera

que sea la fuente, cuando la información llegue al Data Warehouse necesita ser

medida de la misma manera.

 

       Convenciones de Nombramiento El mismo elemento es frecuentemente referido

por nombres diferentes en las diversas aplicaciones. El proceso de transformación

asegura que se use preferentemente el nombre de usuario.

 

       Fuentes Múltiples El mismo elemento puede derivarse desde fuentes múltiples.

En este caso, el proceso de transformación debe asegurar que la fuente apropiada sea

usada, documentada y movida al depósito.

 

 

Figura No. 3

 

Tal como se muestra en la figura, los puntos de integración afectan casi todos los

aspectos del diseño ( las características físicas de los datos, la incompatibilidad de tener

más de una fuente de datos, el problema de estándares de denominación inconsistentes,

formatos de fecha inconsistentes, cualquiera que sea la forma del diseño, el resultado es el

mismo ) la información necesita ser almacenada en el Data Warehouse en un modelo

globalmente aceptable y singular, aún cuando los sistemas operacionales almacenen los

datos de manera diferente.

 

Cuando el analista de sistema de soporte de decisiones observe el Data Warehouse,

su enfoque debe estar en el uso de los datos que se encuentre en el depósito, antes de

preguntarse sobre la confiabilidad o consistencia de los datos.

 

Esta es la característica más importante del Data Warehouse. Con la aplicación de

esta, toma un gusto muy corporativo. La integración de los datos muestra muchas rutas

distintas en convenciones consistentes de nombre, medidas de variables, estructuras de

codificación, atributos físicos de datos, entre otros. Contrasta la información encontrada, con

la carencia de integración en los ambientes de las aplicaciones. Al transcurrir los años,

muchos diseñadores han hecho sus decisiones individuales sobre cómo una aplicación debe

ser construida. El estilo y diseño de decisiones hecho a la medida por parte del diseñador

muestran muchas maneras, así como diferencias en codificación, diferencias en las

estructuras clave, en las características físicas, entre convenciones de nombre.

 

Como sea la edición de diseño, el resultado es el mismo: los datos necesitan ser

almacenados en el Data Warehouse de manera única, globalmente aceptada aún cuando los

sistemas operacionales principales almacenen los datos de manera distinta.

 1.2.3. 2.2.3.           De Tiempo Variante

 Toda la información del Data Warehouse es requerida en algún momento. Esta

característica básica de los datos en un depósito, es muy diferente de la información

encontrada en el ambiente operacional. En éstos, la información se requiere al momento de

accesar. En otras palabras, en el ambiente operacional, se accesa a una unidad de

información y se espera que los valores requeridos se obtengan a partir del momento de

acceso.

 Como la información en el Data Warehouse es solicitada en cualquier momento (es

decir, no "ahora mismo"), los datos encontrados en el depósito se llaman de "tiempo

variante". Los datos históricos son de poco uso en el procesamiento operacional. La

información del depósito, debe incluir los datos históricos para usarse en la identificación y

evaluación de tendencias. (Ver Figura No. 4).

 

Figura No. 4

  

El tiempo variante se muestra de varias maneras:

       La más simple es que la información representa los datos sobre un horizonte de

tiempo largo (desde cinco a diez años). El horizonte de tiempo representado para el

ambiente operacional es mucho más corto desde valores actuales hasta sesenta a

noventa días.

 

Las aplicaciones que tienen un buen rendimiento y están disponibles para el

procesamiento de transacciones, deben llevar una cantidad mínima de datos y algún

grado de flexibilidad. Por ello, las aplicaciones operacionales tienen un corto

horizonte de tiempo, debido al diseño de aplicaciones rígidas.

 

       La segunda manera es la que muestra el tiempo variante en el Data Warehouse

está es la estructura clave. Cada estructura clave en este contiene, implícita o

explícitamente, un elemento de tiempo como día, semana, mes..

El elemento de tiempo es casi siempre la clave en el Data Warehouse. En

ocasiones, el elemento de tiempo existe implícitamente, como el caso en que un

archivo completo se duplica al final del mes, o al cuarto.

 

       La tercera manera en que aparece el tiempo variante es cuando la información

del Data Warehouse, una vez registrada correctamente, no puede ser actualizada.

La información de contenida en este es, para todos los propósitos prácticos, una

serie larga de vistas instantáneas (snapshots).

Si las vistas instantáneas de los datos se han tomado incorrectamente,

entonces pueden ser cambiados. Asumiendo que las vistas instantáneas se han

tomado adecuadamente, ellos no son alterados una vez hechos. En algunos casos

no es ético, alterar las vistas instantáneas en el Data Warehouse. Los datos

operacionales, son requeridos a partir del momento de acceso y pueden actualizarse

de acuerdo a la necesidad.

 

Todos los datos en el Data Warehouse son exactos en cualquier momento en el

tiempo. Esta característica básica, es muy distinta a los datos encontrados en el ambiente

operacional. En este ambiente, los datos son exactos en el momento de acceso. En otras

palabras, en un ambiente operacional, cuando se accesan, se espera que se reflejen valores

exactos a ese momento de acceso.

 

La varianza en el tiempo de los datos del Data Warehouse de muestra de varias

maneras. Las aplicaciones que se ejecutan estan disponibles para el proceso transaccional,

éstos deben acarrear la misma cantidad de datos si tienen algún grado de flexibilidad. Por

consiguiente, las aplicaciones operacionales tienen un horizonte de tiempo corto. La

estructura, es una manera en la que la varianza de tiempo se muestra en el Data

Warehouse.

 

1.2.4. 2.2.4.           No Volátil 

La información es útil sólo cuando es estable. Los datos operacionales cambian sobre

una base momento a momento. La perspectiva esencial para el análisis y la toma de

decisiones, requiere una base de datos estable.

 

En la Figura No.5 se muestra que la actualización (insertar, borrar y modificar), se hace

regularmente en el ambiente operacional sobre una base de registro. Pero la manipulación

básica de los datos que ocurre en el Data Warehouse es mucho más simple. Hay dos únicos

tipos de operaciones: la carga inicial de datos y el acceso a los mismos. No hay

actualización en el depósito, como una parte normal de proceso.

 

Hay algunas consecuencias muy importantes de esta diferencia básica, entre el

procesamiento operacional y del Data Warehouse. En el nivel de diseño, la necesidad de ser

precavido para actualizar las anomalías no es un factor de este, ya que no se hace la

actualización de datos. Esto significa que en el nivel físico de diseño, se pueden tomar

libertades para optimizar el acceso a los datos, particularmente al usar la normalización y

denormalización física.

 

Otra consecuencia de la simplicidad de la operación del Data Warehouse está en la

tecnología, utilizada para correr los datos en el depósito. Teniendo que soportar la

actualización de cada registro en modo en línea (como es frecuente en el caso del

procesamiento operacional) requiere que la tecnología tenga un fundamento muy complejo

debajo de una fachada de simplicidad.

 

Figura No. 5

 En el Data Warehouse no es necesario el procesamiento. La fuente de casi toda la

información es el ambiente operacional. A simple vista, se puede pensar que hay

redundancia masiva de datos entre los dos ambientes. La primera impresión de muchas

personas se centra en la gran redundancia de datos, entre el ambiente operacional y el

ambiente de Data Warehouse. Dicho razonamiento es superficial y demuestra una carencia

de entendimiento con respecto a qué ocurre en el Data Warehouse. De hecho, hay una

mínima redundancia de datos entre ambos ambientes.

Se debe considerar lo siguiente:

         Los datos se filtran cuando pasan por el ambiente operacional al depósito.

Existen datos que nunca salen del ambiente operacional. Solamente los datos que

se necesitan ingresán al ambiente de Data Warehouse.

 

       El horizonte de tiempo de los datos es diferente de un ambiente a otro. La

información en el ambiente operacional es reciente con respecto a la del Data

Warehouse. Desde la perspectiva de los horizontes de tiempo únicos, hay poca

superposición entre los ambientes operacional y de Data Warehouse.

 

       El Data Warehouse contiene un resumen de la información que no se encuentra

en el ambiente operacional.

 

       Los datos experimentan una transformación fundamental cuando pasa al Data

Warehouse. La mayor parte de los datos se alteran significativamente al ser

seleccionados y movidos hacia él. Dicho de otra manera, la mayoría de los datos se

alteran física y radicalmente cuando se mueven al depósito. No son los mismos

datos que residen en el ambiente operacional desde el punto de vista de integración.

 

En vista de estos factores, la redundancia de datos entre los dos ambientes es una

ocurrencia rara, que resulta en menos de 1%.

 En resumen, las actualizaciones, inserciones, borrados y cambios, son regularmente

hechos en el ambiente operacional. Pero la manipulación básica de los datos que ocurre en

el Data Warehouse es muy simple. Solamente hay dos clases de operaciones que ocurren

en él, la carga y el acceso de datos. No hay actualización en este como parte normal del

procesamiento. Existen consecuencias poderosas de éstas diferencias básicas, entre el

procesamiento operacional y el procesamiento del Data Warehouse. En el diseño, la

necesidad de ser cautelosos de las anomalías de actualización no es un factor en este, ya

que no se hace una actualización. Esto significa que el ámbito del diseño físico, pueden

tomarse algunas libertades para optimizar el acceso de los datos, particularmente en el trato

con los beneficios de la normalización y la denormalización física.

  1.3. 2.3.      Estructura del Data Warehouse   

Existen estructuras distintas para los Data Warehouse. Hay niveles diferentes de

esquematización y detalle que lo delimitan. En la figura No. 6 se muestra la estructura de este. Se

muestran los diferentes componentes y son:

         Detalle de datos actuales: El interés más importante radica en el detalle de los

datos actuales, debido a que:

o o        Reflejan las ocurrencias más recientes, las que son de gran interés

o o        Es voluminoso, ya que se almacena al más bajo nivel de granularidad.

o o        Siempre se almacena en disco, es de fácil acceso, aunque su

administración es costosa y compleja.

 

       Detalle de datos antiguos: Son aquellos que se almacenan sobre alguna forma de

almacenamiento masivo. No son frecuentemente accesados y se almacenan a un nivel

de detalle consistente en los datos detallados actuales. Mientras no sea prioritario el

almacenamiento en un medio de almacenaje alterno, a causa del gran volumen de datos

y al acceso no frecuente de los mismos, es poco usual utilizar el disco como medio de

almacenamiento.

 

       Datos ligeramente resumidos: Son aquellos que provienen desde un bajo nivel de

detalle encontrado al nivel de detalle actual. Este siempre se almacena en disco. Los

puntos en los que se basa el diseñador para construirlo son:

o o        La unidad de tiempo se encuentre sobre la esquematización hecha.

o o        Contenidos (atributos) tienen los datos ligeramente resumidos.

 

 

Figura No. 6 

       Datos completamente resumidos: Estos datos son compactos y fácilmente

accesibles.

         Metadata El componente final del Data Warehouse es el de la metadata. De muchas

maneras esta se sitúa en una dimensión diferente al de otros datos del Data Warehouse,

debido a que su contenido no es tomado directamente desde el ambiente operacional.

La metadata juega un rol especial y muy importante en el Data Warehouse y es

usada como:

o o        Un directorio para ayudar al analista a ubicar los contenidos del Data

Warehouse.

o o        Una guía para el mapeo de datos en la transformación, del ambiente

operacional al del Data Warehouse.

o o        Una guía de los algoritmos usados para la esquematización entre el

detalle de datos actual, con los ligeramente resumidos y éstos, con los datos

completamente resumidos.

 

La metadata juega un papel importante en un ambiente Data Warehouse que en el

operacional clásico. A fin de recordar los diferentes niveles de los datos encontrados en el

Data Warehouse, se considera el ejemplo mostrado en la Figura No. 7.

 

El detalle de ventas antiguas son las que se encuentran antes de 1998. Todos los detalles

de ventas desde 1988 (o cuando el diseñador inició la colección de los archivos) son almacenados

en el nivel de detalle de datos más antiguo.

 

El detalle actual contiene información de 1998 a 1999. En general, las ventas no se ubica

nen en el nivel actual hasta que pase, por lo menos, veinticuatro horas hasta que la información de

ventas este disponible en el ambiente operacional.

 

Figura No. 7

 

Hay un retraso de veinticuatro horas, entre el tiempo en que el ambiente operacional se hace

un nuevo ingreso de venta y cuando la información de la venta haya ingresado al Data Warehouse.

El detalle de ventas son resumidas semanalmente por línea de subproducto y por región, para

producir un almacenamiento de datos ligeramente sitentizado. El detalle de ventas semanal se

adiciona en forma mensual, según una gama de líneas, para producir los datos completamente

consolidados.

 

Generalmente, la metadata contiene:

       La estructura de datos.

       Los algoritmos usados para la esquematización

       El mapping desde el ambiente operacional al Data Warehouse

 

La información adicional que no se esquematiza es almacenada en el Data Warehouse. En

ocasiones, se hace el análisis y se produce un tipo de sintesis. El único tipo de programa que se

almacena permanentemente en el Data Warehouse, es el de datos que son usados

frecuentemente. Si un analista produce un esquema que tiene probabilidad muy baja de ser usado

nuevamente, entonces no es almacenado en el Data Warehouse.

 

1.4. 2.4.               Arquitectura de un Data Warehouse   

La razón por la que el desarrollo de un Data Warehouse crece rápidamente, es porque

realmente es una tecnología muy entendible. De hecho, representa la estructura amplia de una

empresa para administrar los datos informacionales dentro de la organización. A fin de comprender

cómo se relacionan todos los componentes involucrados en una estrategia Data Warehouse, es

esencial tener una Arquitectura para este.

  

1.4.1. 2.4.1.           Elementos constituyentes de una Arquitectura Data Warehouse

 La Arquitectura Data Warehouse (DWA) es la forma de representar la estructura total de

datos, como son comunicación, procesamiento y presentación, esto existe para los usuarios

finales que disponen de una computadora dentro de la empresa.

La arquitectura se constituye de partes interconectadas:

       Base de datos operacional / Nivel de base de datos externo: Los sistemas

operacionales procesan datos para apoyar las necesidades de operaciones críticas.

Para hacer eso, se han creado las bases de datos operacionales históricas que

proveen una estructura de procesamiento eficiente, para un número relativamente

pequeño de transacciones comerciales bien definidas. Sin embargo, a causa del

enfoque limitado de los sistemas operacionales, las bases de datos diseñadas para

soportar estos, tienen dificultad al acceder los datos para otra gestión o propósitos

informáticos. Esta, es amplificada por el hecho que muchos de estos sistemas

tienen de 10 a 15 años de antigüedad. El tiempo de algunos de estos sistemas

significa que la tecnología de acceso a los datos disponible para obtener los datos

operacionales, es antigua.

 

La meta del Data Warehouse es liberar la información que se almacena en

bases de datos operacionales y combinarla con la información desde otra fuente de

datos, generalmente externa. Cada vez, las organizaciones grandes adquieren

datos adicionales desde bases de datos externas.

 

       Nivel de acceso a la información: Es el nivel del que el usuario final se

encarga directamente. En particular, representa las herramientas que el este

normalmente usa diariamente. Este nivel incluye el hardware y software que

muestran la información en pantalla y emitir reportes de impresión, hojas de cálculo,

gráficos y diagramas para el análisis y presentación. Hace dos décadas que el nivel

de acceso a la información se ha expandido enormemente, especialmente a los

usuarios finales quienes se han volcado a las PCs monousuarias y las PCs en

redes.

Actualmente, existen herramientas sofisticadas para manipular, analizar y

presentar los datos, sin embargo, hay problemas significativos al tratar de convertir

los datos tal como son recolectados y que se encuentran contenidos en los sistemas

operacionales en información fácil y transparente para las herramientas de los

usuarios finales. Una de las claves para esto es encontrar un lenguaje de datos

común que se use a través de toda la empresa.

       Nivel de acceso a los datos: El nivel de acceso a los datos de la arquitectura

Data Warehouse se involucra con el nivel de acceso a la información para conversar

en el nivel operacional. En la red mundial de hoy, el lenguaje de datos común que

surge es SQL (Structured Query Language). Originalmente, SQL fue desarrollado

por IBM como un lenguaje de consulta, pero en los últimos veinte años ha llegado a

ser el estándar para el intercambio de datos.

 

El nivel de acceso a los datos no solamente conecta DBMSs (Bases de Datos

Relacionales) diferentes y sistemas de archivos sobre el mismo hardware, sino

también a los fabricantes y protocolos de red. Una de las claves de una estrategia

Data Warehouse es proveer a los usuarios finales con "acceso a datos universales".

El acceso a los datos universales significa que, teóricamente por lo menos, los

usuarios finales sin tener en cuenta la herramienta de acceso a la información o

ubicación, deberían ser capaces de accesar a cualquier o todos los datos en la

empresa que es necesaria para ellos. El nivel de acceso a los datos entonces es

responsable de la interfase entre las herramientas de acceso a la información y las

bases de datos operacionales. En algunos casos, esto es todo lo que un usuario

final necesita.

 

       Nivel de Directorio de Datos (Metadata): A fin de proveer el acceso a los datos

universales, es absolutamente necesario mantener alguna forma de directorio de

datos o repositorio de la información metadata. A fin de tener un depósito totalmente

funcional, es necesario tener una variedad de metadata disponibles, información

sobre las vistas de datos de los usuarios finales e información sobre las bases de

datos operacionales. Idealmente, los usuarios finales deberían de accesar a los

datos desde el Data Warehouse (o desde las bases de datos operacionales), sin

tener que conocer dónde residen los datos o la forma en que se han almacenado.

 

       Nivel de Gestión de Procesos: El nivel de gestión de procesos tiene que ver

con la programación de diversas tareas que deben realizarse para construir y

mantener el Data Warehouse y la información del directorio de datos. Este nivel

puede depender del alto nivel de control de trabajo para muchos procesos que

deben ocurrir para mantener el Data Warehouse actualizado.

 

       Nivel de Mensaje de la Aplicación: El nivel de mensaje de la aplicación tiene

que ver con el transporte de información alrededor de la red de la empresa. El

mensaje de aplicación se refiere también como "subproducto", pero puede involucrar

sólo protocolos de red. Puede usarse por ejemplo, para aislar aplicaciones

operacionales o estratégicas a partir del formato de datos exacto, recolectar

transacciones o los mensajes y entregarlos a una ubicación segura en un tiempo

seguro.

       Nivel Data Warehouse (Físico): En el Data Warehouse es donde ocurren los

datos actuales, usados principalmente para usos estratégicos. En algunos casos, se

puede pensar del Data Warehouse simplemente como una vista lógica o virtual de

datos. En muchos ejemplos, el Data Warehouse puede no involucrar

almacenamiento de datos. En un Data Warehouse físico, copias, en algunos casos,

muchas copias de datos operacionales y/o externos, son almacenados realmente en

una forma que es fácil de acceder y es altamente flexible. Cada vez más, los Data

Warehouse son almacenados sobre plataformas cliente / servidor, pero por lo

general se almacenan sobre mainframes o computadoras grandes.

 

       Nivel de Organización de Datos: El componente final de la arquitectura Data

Warehouse es la organización de los datos. Se llama también gestión de copia o

réplica, pero de hecho, incluye todos los procesos necesarios como seleccionar,

editar, resumir, combinar y cargar datos en el depósito y acceder a la información

desde bases de datos operacionales y/o externas.

 

1.5. 2.5.               Operaciones en un Data Warehouse 

a) Sistemas Operacionales Los datos administrados por los sistemas de aplicación

operacionales son la fuente principal de datos para el Data Warehouse. Las bases de datos

operacionales se organizan como archivos indexados, bases de datos de redes/jerárquicas o

sistemas de base de datos relacionales.

 b) Extracción, Transformación y Carga de los Datos Se requieren herramientas de

gestión de datos para extraer datos desde bases de datos y/o archivos operacionales, luego

es necesario manipular o transformar los datos antes de cargar los resultados en el Data

Warehouse. Tomar los datos desde varias bases de datos operacionales y transformarlos en

datos requeridos para el depósito, se refiere a la transformación o a la integración de datos.

Las bases de datos operacionales, diseñadas para el soporte de varias aplicaciones de

producción, frecuentemente difieren en el formato. Los mismos elementos de datos, si son

usados por aplicaciones diferentes o administrados por diferentes software de adminitración

de bases de datos (DBMS), pueden definirse al usar nombres de elementos inconsistentes,

que tienen formatos inconsistentes y/o ser codificados de manera diferente. Todas estas

inconsistencias deben resolverse antes que los elementos de datos sean almacenados en el

Data Warehouse.

c) Metadata Otro paso necesario es crear la metadata. Esta describe los contenidos del

Data Warehouse. Consiste de definiciones de los elementos de datos en el depósito,

sistemas de los elementos fuente. Los datos, se integran y transforman antes de ser

almacenados en información similar.

 

d) Acceso de usuario final Estos accesan al Data Warehouse por medio de herramientas

de productividad basadas en Interfase gráfica de usuario (GUI). Proveen a los usuarios del

Data Warehouse muchos de estos tipos de instrumentos. Estos pueden incluir software de

consultas, generadores de reportes, procesamiento analítico en línea, data/visual mining,

etc., dependiendo de los tipos de usuarios y sus requerimientos particulares. Sin embargo,

una sola no satisface a todos, por lo que es necesaria la integración de una serie de

utencilios.

 

e) Plataforma del Data Warehouse La plataforma para el Data Warehouse es casi siempre

un servidor de base de datos relacional. Cuando se manipulan volúmenes muy grandes de

datos puede requerirse una configuración en bloque. Los extractos de los datos

integrados/transformados se cargan en el Data Warehouse. La elección de la plataforma es

crítica. El depósito crece y hay que comprender los requerimientos después de 3 o 5 años.

Muchas de las organizaciones quieran o no escogen una plataforma por diversas razones: el

Sistema X es el elegido o el Y está disponible sobre uno que ya se tiene. Uno de los errores

más grandes que las organizaciones cometen al seleccionar la plataforma, es que ellos

presumen que el sistema (hardware y/o DBMS) escala con los datos.

 

El sistema de depósito ejecuta las consultas que se pasa a los datos por el software de

acceso del usuario. Aunque uno de estos visualiza las consultas desde el punto de vista de

un GUI, estas típicamente se formulan como pedidos SQL, porque es un lenguaje universal y

el estándar hecho para el acceso a datos.

 

f) Datos Externos Dependiendo de la aplicación, el alcance del Data Warehouse se

extiende por la capacidad de accesar los datos externos. Por ejemplo, los datos accesibles

por medio de servicios de computadora en línea y/o vía Internet, pueden estar disponibles a

los usuarios del Data Warehouse.

Evolución del Depósito

Construir un Data Warehouse es una tarea grande. No es recomendable emprender el

desarrollo en la empresa como un proyecto cualquiera. Más bien, se recomienda que los

requerimientos de una serie de fases se desarrollen e implementen en modelos consecutivos

que permitan un proceso de culminación más gradual e iterativo. No existe organización que

triunfe en el desarrollo del Data Warehouse de la empresa, en un sólo paso. Muchas, lo han

logrado luego de un desarrollo por pasos. Los avances previos evolucionan conjuntamente

con la materia que está siendo agregada.

 

Los datos en el Data Warehouse no son volátiles y es un repositorio de sólo lectura.

Sin embargo, pueden añadirse nuevos elementos sobre una base regular para que el

contenido siga la evolución de estos en la base de datos fuente, tanto en los contenidos

como en el tiempo. Uno de los desafíos de mantener un Data Warehouse, es idear métodos

para identificar información nueva o modificada en las bases de datos operacionales.

Algunas maneras para identificarla incluyen insertar fecha/tiempo en los registros y entonces

crear copias actualizadas y copiarla de los registros de transacción y/o base de datos diarias.

Estos elementos nuevos y/o modificados son extraídos, integrados, transformados y

agregados al Data Warehouse en pasos periódicos programados. Como se añaden las

nuevas ocurrencias, los datos antiguos son eliminados. Por ejemplo, si los detalles de un

sujeto particular se mantienen por 5 años, como se agregó la última semana, la anterior es

eliminada.

  1.6. 2.6.               Transformación de datos y metadata  

1.6.1. 2.6.1.           Transformación de Datos

El desafío de cualquier implementación de Data Warehouse, es transformar los datos.

Estos se encarga de las inconsistencias en los formatos y la codificación, que pueden existir

dentro de una base de datos única y que casi siempre existen cuando múltiples bases de

datos contribuyen lo constituyen. En la Figura No. 8 se ilustra una forma de inconsistencia,

en la que el género se codifica de manera diferente en tres bases de datos. Los procesos de

transformación se desarrollan para direccionarlas inconsistencias.

 

Figura No. 8

  

La transformación de datos también se encarga de las inconsistencias en el contenido

de estos. Una vez que se toma la decisión sobre las reglas de transformación que se

necesitan, se debe crear e incluir las definiciones en las rutinas de modificación. Se requiere

una planificación cuidadosa y detallada para transformar datos inconsistentes en conjuntos

conciliables y consistentes para cargarlos en el Data Warehouse.

 

1.6.2. 2.6.2.           Metadata

Otro aspecto de la arquitectura de Data Warehouse es crear soporte a la metadata. Es

un concepto genérico, pero cada implementación de esta usa técnicas y métodos

específicos. Estos son dependientes de los requerimientos de cada organización, de las

capacidades existentes y de los requerimientos de interfase de usuario. No hay normas para

la metadata, por lo que debe definirse desde el punto de vista del software para Data

Warehouse seleccionado.

La metadata incluye los siguientes aspectos:

       Las estructuras de datos que dan una visión al administrador.

       Las definiciones del sistema de registro desde el cual se construye el Data

Warehouse.

       Las especificaciones de transformaciones de datos que ocurren tal como la

fuente se replica al Data Warehouse.

       El modelo de datos del Data Warehouse (es decir, los elementos y sus

relaciones).

       Un registro de cuando los nuevos elementos se agregan al Data Warehouse y

cuando los antiguos se eliminan o se resumen.

       Los niveles y el método de sumarización y las tablas de registros de su Data

Warehouse.

 

Algunas implementaciones de la metadata incluyen definiciones de las vistas

presentadas a los usuarios del Data Warehouse. Se definen para favorecer las preferencias

variadas de diversos grupos de usuarios. En implementaciones, estas descripciones se

almacenan en un Catálogo de Información. Los esquemas y subesquemas para bases de

datos operacionales, forman una fuente óptima de entrada cuando se crea la metadata.

Hacer uso de la documentación existente, especialmente cuando está disponible en forma

electrónica, acelera el proceso de definición de la medatada. Esta, sirve en un sentido, como

el corazón del ambiente Data Warehouse. Crear definiciones completas y efectivas es un

proceso que consume tiempo, pero lo mejor de las definiciones son los esfuerzos que da

como resultado el mantenimiento del Data Warehouse.

 1.7. 2.7.               Flujo de datos

 Existe un flujo de datos normal y predecible dentro del Data Warehouse. La Figura No. 9

muestra ese flujo. La información ingresa al Data Warehouse desde el ambiente operacional. Al

introducirse al Data Warehouse, van al nivel de detalle actual. Se queda allí y se usa hasta que

ocurra uno de los tres eventos siguientes:

       Se elimine

       Se resuma

       Se archive

Con el proceso de desactualización en un Data Warehouse se mueve el detalle de datos

actual los antiguos, basado en el tiempo de estos. El proceso de esquematización usa el detalle

para calcularlos en forma ligera y completamente resumidos.

 Figura No. 9

   

1.8. 2.8.               Usos del Data Warehouse

Los datos operacionales y los del Data Warehouse son accesados por usuarios que los usan

de maneras diferentes. Se muestra en el siguiente cuadro las diferencias:

 

Uso deBase de Datos Operacionales

Uso deData Warehouse

Muchos usuarios concurrentes. Pocos usuarios concurrentes.

Consultas predefinidas y actualizadas.Consultas complejas, frecuentemente no anticipadas.

Cantidades pequeñas de datos detallados. Cantidades grandes de datos detallados.

Requerimientos de respuesta inmediata. Requerimientos de respuesta no críticas.

  

1.8.1. 2.8.1.           Maneras diferentes de uso de datos

Los usuarios de un Data Warehouse necesitan accesar datos complejos,

frecuentemente desde fuentes múltiples y de formas no predecibles. Cuando accesan los

operacionales, efectúan tareas predefinidas que, generalmente requieren acceso a una base

de datos de una aplicación. Por el contrario, los que accesan al Data Warehouse, efectúan

tareas que requieren acceso a un conjunto de datos desde fuentes múltiples y no son

predecibles. Lo único que se conoce es el conjunto inicial de datos que se han establecido

en el depósito. Por ejemplo, un especialista en el cuidado de la salud necesita acceder los

actuales e históricos para analizar las tendencias de costos, usando un conjunto de

consultas predefinidas. Por el contrario, un representante de ventas necesita acceder a los

datos de cliente y producto para evaluar la eficacia de una campaña de mercadeo, creando

consultas base para encontrar necesidades definidas.

 

       Sólo pocos usuarios accesan los datos concurrentemente. En contraste a la

producción de sistemas que pueden manejar cientos o miles de usuarios concurrentes,

al Data Warehouse accesa un limitado conjunto de usuarios en tiempo determinado.

 

       Los usuarios generan un procesamiento no predecible complejo. Se generan

consultas complejas. La respuesta a una consulta conduce a la formulación de otras

preguntas más detalladas, en un proceso iniciando del nivel mas alto y bajando a detalle

en niveles (drilling down). El Data Warehouse puede incluirlos en resúmenes múltiples,

derivado de un conjunto principal, único, de datos detallados, para soportar este tipo de

uso.

 

Los usuarios frecuentemente comienzan buscando en los datos resumidos y como

identifican áreas de interés, comienzan a accesar al conjunto detallado. Los conjuntos

resumidos representan el "Qué" de una situación y los conjuntos detallados permiten a

los usuarios construir un cuadro sobre "Cómo" se ha derivado esa situación.

 

       Las consultas de los usuarios accesan a cantidades grandes de datos. Debido

a la necesidad de investigar tendencias y evaluar las relaciones entre muchas clases de

datos, las consultas al Data Warehouse permiten accesar a volúmenes muy grandes

tanto detallados como resumidos. Debido a los requerimientos de datos históricos, los

Data Warehouse evolucionan para llegar a un tamaño más grande que sus orígenes

operacionales (de 10 a 100 veces más grande).

 

       Las consultas de los usuarios no tienen tiempos de respuesta críticos Las

transacciones operacionales necesitan una respuesta inmediata porque un cliente puede

estar esperando una solución. En el Data Warehouse, por el contrario, tiene un

requerimiento de respuesta no-crítico porque el resultado frecuentemente se usa en un

proceso de análisis y toma de decisiones. Aunque los tiempos de respuesta no son

críticos, los usuarios esperan una resolución dentro del mismo día en que es hecha la

consulta.

 

Por lo general, los niveles de datos dentro del Data Warehouse reciben diferentes usos. A

más alto nivel de esquematización, se tiene mayor uso de estos. Hay una buena razón para mover

una organización al paradigma sugerido en la figura No. 9, la utilización del recurso. Los datos

resumidos, permiten capturarlos en forma rápida y eficiente. Si en una tarea se hace mucho

procesamiento a niveles de detalle del Data Warehouse, entonces se consumen muchos recursos

de máquina. Es mejor hacer el procesamiento a niveles más altos de esquematización.

 

Para muchas tareas, el analista de sistemas de soporte de decisiones usa la información al

nivel de detalle en un PreData Warehouse. La seguridad del detalle se consigue de muchas

maneras, aun cuando estén disponibles otros niveles de esquematización. Una actividad del

diseñador es desconectar al usuario del sistema de soporte de decisiones del uso constante de

datos a nivel de detalle más bajo.

 El diseñador de datos tiene dos predisposiciones:

       Instalar un sistema donde el usuario final pague por los recursos consumidos

       Señalar el mejor tiempo de respuesta que puede obtenerse cuando se trabaja con

los datos a un nivel alto de esquematización, a diferencia de un pobre tiempo de

respuesta que resulta de trabajar con los niveles bajos de detalle.

 

1.9. 2.9.               Ventajas y desventajas de un Data Warehouse  

Construir un Data Warehouse puede dar a las compañías ventajas estratégicas sobre la

competencia. Estas ventajas provienen de varios recursos:

 

       Acceso a toda la información de la empresa. Se consolida información de diferentes

sistemas origen, sin importar si estos provienen de la misma o varias fuentes.

 

       Consistencia de la información. Se logra al consolidarla ide varios departamentos a

uno solo. Es más fácil la toma de decisiones con la información consolidada que separada.

 

       Facilidad de análisis de la información. El hecho de tener la información ya

almacenada y consolidada hace más fácil realizar el análisis de la misma.

 

       Integración de datos de múltiples sistemas incompatibles a una base de datos

consolidada. Realizar un Data Warehouse provee la ventaja de obtener información de

múltiples fuentes de información sin importar la compatibilidad entre ambas. Esto se realiza

por medio de ODBC u OLEDB.

 

       Beneficios en costos, tiempos y productividad. Un Data Warehouse ayuda a

obtener mejores tiempos de respuesta y mejora el proceso de producción.

 

Se dice que si una empresa quiere buenos negocios, tomar mejores decisiones cercanas a

sus clientes y ventaja competitiva, lo ideal es implementar un Data Warehouse que le ayude a

obtener estos beneficios.

  1.10. 2.10.           Ejemplo de un Data Warehouse  

 Para ilustrar cómo un Data Warehouse puede ayudar a una organización a mejorar sus

operaciones, se muestra un ejemplo de lo que es el desarrollo de actividades sin tener un Data

Warehouse.

          Preparación de un reporte complejo

Se considera 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 está 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 se obtiene desde una base de datos mediante un programa de

extracción de datos, el inventario de otro programa de otra base de datos, la condición de personal

de un tercer programa de extracción y la información histórica desde un backup de cinta magnética

o CD-ROM.

 

Lo más interesante es que se pide otro informe que continúe al primer informe (debido a que

las preguntas se originaron a partir del anterior). El hecho es, que ninguno de los trabajos

realizados hasta aquí (por ejemplo, diversos programas de extracción) se usan para los próximos o

para cualquier reporte subsiguiente. El tiempo y el esfuerzo que se ha desperdiciado por un

enfoque anticuado es muy grande. Este ejemplo se muestra en la Figura No. 10. Las

inconsistencias se identifican en cada conjunto de datos extraídos y resolverse, por lo general,

manualmente. Cuando se completa todo este procesamiento, el reporte se le da formato, se

imprime, se revisa y se transmite. 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 son independientes y caros, desde el punto de vista de recursos y productividad.

 

Figura No. 10

 

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

se cargan en el Data Warehouse, 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 más simple.

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

       Se crea una sola fuente.

 

1.11. 2.11.           Consideraciones adicionales  

Hay consideraciones adicionales que se tienen en cuenta al construir y administrar el Data

Warehouse:

 

       Indice. La información de los niveles de esquematización más altos pueden ser

libremente indexados, mientras que las de los niveles bajos de detalle, por ser tan

voluminosa, pueden ser indexados moderadamente. Por lo mismo, los datos en los niveles

altos de detalle son reestructurados fácilmente, mientras que el volumen de datos en los

niveles más inferiores es tan grande, que los datos no son fácilmente reestructurados. Por

consiguiente, el modelo de datos y el diseño clásico fundamentan que el Data Warehouse

es aplicado exclusivamente al nivel actual de detalle. En otras palabras, las actividades de

modelamiento de datos no se aplican a los niveles de esquematización, en casi todos los

casos.

 

       Partición de la información en el Data Warehouse. El nivel de detalle actual es

siempre particionado. La partición se hace de dos maneras: al nivel de DBMS y al nivel de

la aplicación. En la partición DBMS, se conoce las particiones y se administra por

consiguiente. En el caso de la partición de las aplicaciones, sólo los programadores de las

mismas conocen las particiones y la responsabilidad de administración es asignada a ellos.

Al interior de las particiones DBMS, muchos de los trabajos de infraestructura se hacen

automáticamente. Pero existe un elevado grado de rigidez asociada con la gestión

automática de las particiones. En el caso de las particiones de las aplicaciones del Data

Warehouse, la mayor parte del trabajo recae sobre el programador, pero el resultado final

es que la gestión de datos es más flexible.

 

1.12. 2.12.        Excepciones en el Data Warehouse  

Mientras que los componentes del Data Warehouse trabajan de acuerdo al modelo descrito

para casi todos los datos, hay pocas excepciones útiles que se discuten:

 

       Datos públicos resumidos. Son los que se calculan fuera del Data Warehouse pero

se usan a través de la corporación. Los datos públicos resumidos, se almacenan y

administran en el Data Warehouse, aunque su cálculo se haya hecho fuera de él.

 

       Datos Externos. Son considerados como excepción.

 

       Detalle de los datos permanentes. Resulta de la necesidad de una corporación para

almacenar los datos a un nivel detallado permanentemente por razones éticas o legales.

Si en una corporación se expone a los trabajadores a sustancias peligrosas existe una

necesidad de detalle de datos permanente. Si en una corporación se produce un producto

que involucra la seguridad pública, tal como la construcción de las partes de aviones,

existe una necesidad permanentes. Si una corporación se compromete con contratos

peligrosos, existe una necesidad de detalle de datos permanentes.

 

Las organizaciónes no dejan los detalles porque en futuros años, en el caso de una

demanda, una notificación, un edificio en disputa, etc., se incrementa la exposición de la

compañía. Por lo tanto hay un único tipo de datos en el Data Warehouse conocido como

“Detalle de datos permanentes”. Este comparte las mismas consideraciones como otro

Data Warehouse, excepto que:

 

       El medio donde se almacenan los datos debe ser seguro.

       Los datos deben permitir ser restaurados.

 

Los datos necesitan un tratamiento especial en su indexación, ya que de otra manera

pueden no ser accesibles aunque se haya almacenado con mucha seguridad.

 

 

CAPITULO III

 2. 3.      PROCESO DE ELABORACION DE UN DATA WAREHOUSE

   

2.1. 3.1.               Organización

 La planificación es el proceso más importante que determina el tipo de estrategias de Data

Warehouse que una organización inicia. Por tal razón se toman en cuenta los siguientes puntos:

 

2.1.1.3.1.1.        Recopilación de información

         Comprender el proceso del negocio. Primordialmente, se necesita tener claro

como funciona el ciclo administrativo del negocio, comprender la misión, la visión y los

objetivos de la misma, ya que de esto depende el buen o mal diseño del Data

Warehouse.

 

       Identificar objetos, eventos e indicadores clave. Dentro del proceso de

administración existen procesos clave que son los que realmente definen el funcionar

del negocio. Cada uno de estos son identificados para así saber cuáles son los

factores influyentes dentro de éste ciclo. Los eventos como tales son todas las

acciones o sucesos en el tiempo que tienen importancia en el flujo de información que

se lleva a cabo en la empresa, y por consiguiente identificando los anteriores objetos y

eventos, se obtienen los indicadores clave.

 

       Identificar dimensiones, datos y jerarquías. Basados en los requerimientos

necesarios con que se arma un Data Warehouse, este paso forma parte indispensable

del proceso. Las dimensiones ayudan a definir detalladamente los lados de la

información, teniendo de antemano claro la jerarquía que éstos siguen. En toda

empresa, existen datos que son más significativos que otros, y que en un momento

determinado son los indispensables para la toma de decisiones. La buena

identificación de éstos se vé reflejado en la presentación de los datos.

 

Estos tres puntos abarcan el proceso de recopilación de información. Luego que se

realiza este análisis es factible iniciar la creación de Data Warehouse.

 

2.1.2. 3.1.2.           Factores en la planificación 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 se consideran en la planificación de un Data Warehouse:

 

1. 1.       Establecer una asociación de usuarios, gestión y grupos. Se involucran tanto

los usuarios como la gestión quienes aseguran que el Data Warehouse contiene

información que satisface los requerimientos de la empresa. La gestión ayuda a

priorizar la fase de la implementación del Data Warehouse, así como también la

selección de herramientas del usuario. Estos, justifican los costos del Data Warehouse

sobre cómo es "su ambiente" y está basado primero en lo que se espera y segundo, en

el valor comercial real.

 

2. 2.       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, establece 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.

 

3. 3.       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í se agrega los nuevos datos

y/o los modelos en forma permanente. El trabajo continuo con los usuarios y la gestión

es la clave.

 

4. 4.       Implementación incremental. La implementación incremental reduce riesgos y

asegura que el tamaño del proyecto permanecezca manejable en cada fase.

 

5. 5.       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 efectivamente apoya la construcción a lo largo de una empresa.

 

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

implementación del Data Warehouse a través del tiempo para reunir requerimientos de

usuario nuevamente identificados.

 

2.1.3. 3.1.3.           Estrategias para el desarrollo de un Data Warehouse

Antes de desarrollar un Data Warehouse, es importante el desarrollo de una estrategia

equilibrada que sea apropiada para sus necesidades y sus usuarios. Se consideran algunas

preguntas, tales como:

 

       ¿Quién es el auditorio?

       ¿Cuál es el alcance?

       ¿Qué tipo de Data Warehouse se debe construir?

 

Existen estrategias mediante las cuales las organizaciones pueden consiguen un Data

Warehouse.

       Se establece un ambiente "Data Warehouse Virtual", el cual es creado por:

o o        Instalación de un conjunto de facilidades para acceso a datos, directorio y

gestión de proceso.

o o        Entrenamiento de usuarios finales.

o o        Control de cómo se usan realmente las instalaciones del Data Warehouse.

o o        Basados en el uso actual, se crea un Data Warehouse físico que soporte los

pedidos de alta frecuencia.

 

       Se construye una copia de los datos operacionales desde un sistema operacional

único y posibilitar al Data Warehouse una serie de herramientas de acceso a la

información. Esta estrategia tiene la ventaja de ser simple y rápida. Si los datos

existentes son de mala calidad y/o el acceso no ha sido previamente evaluado,

entonces se crea una serie de problemas.

                     Finalmente, en la estrategia Data Warehouse óptima se selecciona el número

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

preguntas y necesidades de acceso a datos.

 

De acuerdo a estas necesidades, se construyen los prototipos Data Warehouse y se

prueban para que los usuarios finales experimenten y modifiquen sus requerimientos. Una

vez se tenga un consenso general de las necesidades, se consigue la información que

proviene de los sistemas operacionales existentes a través de la empresa y/o desde fuentes

externas y se cargan al Data Warehouse. Si se requieren herramientas de acceso a la

información, se permite entonces a los usuarios finales tener permisos requeridos usando

herramientas favoritas propias, o se facilita la creación de sistemas de acceso a la

información multidimensional de alto rendimiento, 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 estas son diferentes, al igual que

su contexto. Además, la tecnología Data Warehouse evoluciona, se aprende cada vez más

sobre el desarrollo de este y resulta en que el único enfoque práctico para al

almacenamiento de datos es la evolución de la persona misma.

 

2.1.4. 3.1.4.           Estrategias para el diseño de un Data Warehouse  El diseño de los Data Warehouse es muy diferente al diseño de los sistemas

operacionales tradicionales. Se consideran los siguientes puntos:

 

       Los usuarios de los Data Warehouse usualmente no conocen mucho sobre los

requerimientos y necesidades como los usuarios operacionales.

 

       El diseño de un Data Warehouse, involucra lo que se piensa en términos más

amplios y con conceptos del negocio más difíciles de definir que en el diseño de un

sistema operacional. Al respecto, un Data Warehouse está bastante cerca a

Reingeniería de los Procesos del Negocio.

                   Finalmente, la estrategia de diseño ideal para un Data Warehouse es de

afuera hacia adentro a diferencia de arriba hacia abajo.

 

A pesar que el diseño del Data Warehouse es diferente al usado en los de sistemas

tradicionales, no es menos importante. El hecho que los usuarios finales tengan dificultad en

definir lo que necesitan, no le disminuye prioridad. En la práctica, los diseñadores de Data

Warehouse usan muchos "trucos" para ayudar a "visualizar" requerimientos. Por ello, son

esenciales los prototipos de trabajo.

 

2.1.5. 3.1.5.           Estrategias para la gestión de un Data Warehouse  

Los Data Warehouse requieren una comercialización y gestión muy cuidadosa.

Se considera lo siguiente:

 

       Un Data Warehouse es una buena inversión sólo si los usuarios finales realmente

obtienen información vital rápida y barata de lo que obtienen con la tecnología actual.

Como consecuencia, la gestión tiene se piensa seriamente sobre cómo se quieren los

depósitos para un eficaz desempeño y cómo se llega a los usuarios finales.

 

       La administración reconoce que el mantenimiento de la estructura del Data

Warehouse es tan crítico como el mantenimiento de cualquier otra aplicación de

misión-crítica. De hecho, la experiencia demuestra que los Data Warehouse han

llegado a ser uno de los sistemas más usados en cualquier organización.

 

       La gestión comprende también que si si en un programa se embarcan Data

Warehouse, se crean nuevas demandas sobre sus sistemas operacionales, que son:

o o        Demandas para mejorar datos.

o o        Demandas para una data consistente .

o o        Demandas para diferentes tipos de datos.

 

2.2. 3.2.               Desarrollo 

2.2.1. 3.2.1.      ¿Por qué construir bloques de Data Warehouse ?

 Para ampliar un negocio, se necesita que la información sea comprensible. Para

muchas compañías, esto significa un gran Data Warehouse que muestre, junto a los datos

no filtrados y dispersos, nuevas formas creativas de presentación. Las herramientas que

los capturan y exploran al detalle evolucionan, así como la capacidad para encontrar las

formas de explotar los datos recolectados. En los últimos años se combinan dos factores

que ayudan a la difusión de los Data Warehouse,

siendo estos:

 

       Se reconocen los beneficios del procesamiento analítico en línea (OLAP), más allá

de las áreas tradicionales de marketing y finanzas. Las organizaciones saben que los

conocimientos inmersos en las masas de datos que rutinariamente recogen sobre sus

clientes, productos, operaciones y actividades comerciales, reducen los costos de

operación y aumentan las rentas, por no mencionar que es más fácil la toma de

decisiones estratégicas.

 

       El crecimiento de la computación cliente/servidor, crea servidores de hardware y

software más poderosos y sofisticados que nunca. Los servidores de hoy compiten con

las mainframes de ayer y ofrecen arquitecturas de memoria tecnológicamente

superiores, procesadores de alta velocidad y capacidades de almacenamiento

masivas.

 

Al mismo tiempo, los Sistemas de Gestión de Base de Datos (DBMS(s)) modernos,

proporcionan mayor soporte para las estructuras de datos complejas. De esta renovación

de hardware y software surgen los Data Warehouse multiterabyte que ahora se ve en

ambientes de cliente/servidor.

 

2.2.2. 3.2.2.      Consideraciones previas al desarrollo de un Data Warehouse

Hay muchas maneras para desarrollar Data Warehouse como tantas organizaciones

existen. Sin embargo, hay un número de dimensiones diferentes que se consideran:

       Alcance de un Data Warehouse

       Redundancia de datos

       Tipo de usuario final

 

                         Alcance del Data Warehouse

El alcance de un Data Warehouse es tan amplio como toda la información

estratégica de la empresa desde su inicio, o es tan limitado como un Data Warehouse

personal para un gerente durante un año. En la práctica, en la amplitud del alcance, el

mayor valor del Data Warehouse es para la empresa y lo más caro y consumidor de tiempo

es crearlo y mantenerlo. Como consecuencia de ello, la mayoría de las organizaciones

comienzan con Data Warehouse funcionales, departamentales o divisionales y luego los

expanden como usuarios que proveen retroalimentación.

 

       Redundancia de datos

Hay tres niveles esenciales de redundancia de datos que las empresas consideran

en las opciones de Data Warehouse:

       Data Warehouse "virtual" o "Point to Point"

       Data Warehouse "centrales"

       Data Warehouse "distribuidos"

No se puede pensar en un único enfoque. Cada opción adapta un conjunto

específico de requerimientos y una buena estrategia de almacenamiento de datos, lo

constituye la inclusión de las tres opciones.

 

       Data Warehouse "Virtual" o "Point to Point". Significa que los usuarios finales

acceden a bases de datos operacionales directamente, usando cualquier herramienta

que posibilite "la red de acceso de datos". Este enfoque provee flexibilidad así como

la cantidad mínima de elementos redundantes que deben cargarse y mantenerse.

Además, se colocan las cargas de consulta no planificadas más grandes, sobre

sistemas operacionales.

 

Como se observa, el almacenamiento virtual es una estrategia inicial, en

organizaciones donde hay una amplia (pero en su mayor parte indefinida) necesidad

de conseguir los datos operacionales, desde una clase relativamente grande de

usuarios finales y donde la frecuencia probable de pedidos es baja. Los depósitos

virtuales de datos proveen un punto de partida para que las organizaciones

determinen qué usuarios finales están buscando realmente.

 

       Data Warehouse "Centrales". Es el concepto inicial que se tiene del Data

Warehouse. Es una única base de datos física, que contiene todos los datos para un

área funcional específica, departamento, división o empresa. Se seleccionan por lo

general donde hay una necesidad común de los datos informáticos y un número

grande de usuarios finales ya conectados a una red o computadora central. Pueden

contener información para cualquier período específico de tiempo. Comúnmente,

contienen de sistemas operacionales múltiples.

Los Data Warehouse centrales son reales. Los datos almacenados son

accesados desde un lugar y se cargan y mantienen sobre una base regular. Se

construyen alrededor de Manejadores de Bases de Datos Relacionales (RDBMs)

avanzados o, en alguna forma, de servidor de base de datos informático

multidimensional.

 

       Data Warehouse Distribuidos. Son aquellos en los cuales ciertos componentes

del depósito se distribuyen a través de un número de bases de datos físicas diferentes.

Cada vez más, las organizaciones grandes toman decisiones a niveles más inferiores

de la organización y a la vez, llevando los datos que se necesitan a la red de área local

(LAN) o computadora local que sirve al que toma decisiones. Involucran la mayoría

redundancias y como consecuencia de ello, se tienen procesos de actualización y

carga más complejos.

 

       Tipo de usuario final  

De la misma forma que hay una gran cantidad de maneras de organizar un Data

Warehouse, también hay una gama cada vez más amplia de usuarios finales.

En general, se consideran tres grandes categorías:

 

         Ejecutivos y gerentes

         "Usuarios Imporantes" o "Buzo de Información" (analistas financieros y de

negocios, ingenieros, etc.)

         Usuarios de soporte (de oficina, administrativos, etc.)

 

Cada una de estas categorías diferentes de usuario tienen su propio conjunto de

requerimientos para los datos, acceso, flexibilidad y facilidad de uso.

 

2.2.3. 3.2.3.      Elementos claves para el desarrollo de un Data Warehouse

Los Data Warehouse exitosos comienzan cuando se escogen e integran

satisfactoriamente tres elementos claves. Un Data Warehouse está integrado por un

servidor de hardware y los DBMS que conforman el depósito. Del lado del hardware, se

combina la configuración de plataformas de los servidores, y aprovechan los saltos

constantes de la potencia del procesador. Del lado del software, la complejidad y el alto

costo de los DBMSs forzan a tomar decisiones drásticas y balances comparativos

inevitables, con respecto a la integración, requerimientos de soporte, desempeño,

eficiencia y confiabilidad.

 

Si se escoge incorrectamente, el Data Warehouse se convierte en una gran empresa

con problemas difíciles de trabajar en su entorno, costoso para arreglar y difícil de justificar.

Para que la implementación del depósito tenga un inicio exitoso, se enfoca hacia tres

bloques claves de construcción:

 

       Arquitectura total del depósito

       Arquitecturas del servidor

       Sistemas de Gestión de Base de Datos

 

A continuación se presentan algunas recomendaciones para tomar las correctas

elecciones para su empresa.

 

       Diseño de la arquitectura  

o o        Arquitectura del Depósito. El desarrollo del Data Warehouse comienza con

la estructura lógica y física de la base de datos del depósito más los servicios

requeridos para operar y mantenerlo. Esta elección conduce a la selección de

otros dos incisos fundamentales: el servidor de hardware y el DBMS. La plataforma

física se centraliza en una sola ubicación o se distribuye regional, nacional o

internacionalmente. A continuación se dan las siguientes alternativas de

arquitectura:

 

         Un plan para almacenar los datos de su compañía, que se obtiene desde

fuentes múltiples internas y externas, se consolida la base de datos en un Data

Warehouse integrado. El enfoque consolidado proporciona eficiencia tanto en

la potencia de procesamiento como en los costos de soporte.

         La arquitectura global distribuye información por función, con datos

financieros sobre un servidor en un sitio, los datos de comercialización en otro

y los datos de fabricación en un tercer lugar.

 

         Una arquitectura por niveles almacena datos altamente resumidos sobre

una estación de trabajo del usuario, con resúmenes más detallados en un

segundo servidor y la información más detallada en un tercero.

 

La estación de trabajo del primer nivel maneja la mayoría de los pedidos para

los datos, con pocos pedidos que pasan sucesivamente a los niveles 2 y 3 para la

resolución. Las computadoras en el primer nivel se optimizan para usuarios de carga

pesada y volumen bajo de datos, mientras que los servidores de los otros niveles son

más adecuados y se procesan los volúmenes pesados de datos, pero cargas más

livianas de usuario.

o o        Arquitectura del servidor. Se decide en una estructura de depósito

distribuida o centralizada, se consideran los servidores que retienen y entregan los

datos. El tamaño de implementación (y las necesidades de la empresa para

escalabilidad, disponibilidad y gestión de sistemas) influye en la elección de la

arquitectura del servidor.

 

o o        Servidores de un solo procesador. Los servidores de un sólo procesador

son los más fáciles de administrar, pero ofrecen limitada potencia de

procesamiento y escalabilidad. Además, un servidor sólo presenta un único punto

de falla, limitando la disponibilidad garantizada del depósito.

 

Se puede ampliar un solo servidor de redes mediante arquitecturas

distribuidas que hacen uso de subproductos, tales como Ambientes de

Computación Distribuida (DCE) o Arquitectura Broker de Objeto Común (CORBA),

para distribuir el tráfico a través de servidores múltiples.

 

Estas arquitecturas aumentan la disponibilidad, debido a que las

operaciones se cambian al servidor de backup si un servidor falla, pero la gestión

de sistemas es más compleja.

 

o o        Multiprocesamiento simétrico. Las máquinas de multiprocesamiento

simétrico (SMP) aumentan mediante la adición de procesadores que comparten la

memoria interna de los servidores y los dispositivos de almacenamiento de disco.

 

La mayoría de multiprocesamientos Simétricos (SMP) se adquieren en

configuraciones mínimas (es decir, con dos procesadores) y se levantan cuando

es necesario, justificando el crecimiento con las necesidades de procesamiento.

La escalabilidad de una máquina SMP alcanza su límite en el número máximo de

procesadores soportados por los mecanismos de conexión.

 

o o        Procesamiento en paralelo masivo Una máquina de procesamiento en

paralelo masivo (MPP), conecta un conjunto de procesadores por medio de un

enlace de banda ancha y de alta velocidad. Cada nodo es un servidor, completo

con su propio procesador (posiblemente SMP) y memoria interna. Para optimizar

una arquitectura MPP, las aplicaciones son "paralelizadas" es decir, diseñadas

para operar por separado, en partes paralelas.

Esta arquitectura es ideal para la búsqueda de grandes bases de datos.

Sin embargo, el Administrador de la Base de Datos (DBMS) que se selecciona es

uno que ofrezca una versión paralela. Y aún entonces, se requiere un diseño y

afinamiento esenciales que obtenga una óptima distribución de los datos y

prevenga "hot spots" o "data skew" (donde una cantidad desproporcionada del

procesamiento es cambiada a un nodo de procesamiento, debido a la partición de

los datos bajo su control).

 

o o        Acceso de memoria no uniforme. La dificultad de mover aplicaciones y los

DBMS a agrupaciones o ambientes realmente paralelos conduce a nuevas y

recientes arquitecturas, tales como el acceso de memoria no uniforme (NUMA).

Crea una gran máquina SMP al conectar múltiples nodos SMP en un solo (aunque

físicamente distribuida) banco de memoria y un ejemplo único de OS. Facilita el

enfoque SMP para obtener los beneficios de rendimiento de las grandes máquinas

MPP (con 32 o más procesadores), mientras se mantiene las ventajas de gestión

y simplicidad de un ambiente SMP estándar. Lo más importante de todo, es que

existen DBMS y aplicaciones que pueden moverse desde un solo procesador o

plataforma SMP a NUMA, sin modificaciones.

 

       Sistemas de gestión de bases de datos

Los Data Warehouse (conjuntamente con los sistemas de soporte de decisión (DSS)

y las aplicaciones cliente/servidor), son los primeros éxitos para el DBMS relacional

(RDBMS). La gran parte de los sistemas operacionales son resultados de aplicaciones

basadas en antiguas estructuras de datos, los depósitos y sistemas de soporte de

decisiones aprovechan el RDBMS por su flexibilidad y capacidad para efectuar consultas

con un único objetivo concreto.

 

Los RDBMS son muy flexibles cuando se usan con una estructura de datos

normalizada. En una base de datos normalizada, no son redundantes y representan las

entidades básicas y las relaciones descritas por los datos (por ejemplo productos, comercio

y transacción de ventas). Pero un procesamiento analítico en línea (OLAP) típico de

consultas que involucra varias estructuras, requiere operaciones de unión para colocar los

datos juntos.

 

El rendimiento de los RDBMS tradicionales es mejor para consultas basadas en

claves que en el contenido. Para el soporte de depósitos a gran escala y para mejorar el

interés hacia las aplicaciones OLAP, los proveedores han añadido nuevas características

al RDBMS tradicional. Estas, también llamadas super relacionales, incluyen el soporte para

hardware de base de datos especializada, tales como la máquina de base de datos

Teradata.

 

Los modelos súper relacionales soportan extensiones para almacenar formatos y

operaciones relacionales y diagramas de indexación especializados. Estas técnicas

mejoran el rendimiento para las recuperaciones basadas en el contenido, al pre juntar

tablas usando índices o mediante el uso de listas de índice totalmente invertidos. Muchas

de las herramientas de acceso a los Data Warehouse explotan la naturaleza

multidimensional de este. Por ejemplo, los analistas de mercadeo buscan en los

volúmenes de ventas por producto, por mercado, por período de tiempo, por promociones

y niveles anunciados y por combinaciones de estos aspectos.

 

La estructura de los datos en una base de datos relacional tradicional, facilita

consultas y análisis a lo largo de dimensiones diferentes que han llegado a ser comunes.

Estos esquemas usan tablas múltiples e indicadores para simular una estructura

multidimensional. Algunos productos, implementan técnicas de almacenamiento y

operadores que soportan estructuras de datos multidimensionales. Mientras las bases de

datos multidimensionales (MDDBs) ayudan directamente a manipular los objetos

multidimensionales (por ejemplo, la rotación fácil de estos para verlos entre dimensiones

diferentes, o las operaciones de movimientos que sucesivamente exponen los niveles más

detallados), se identifican estas cuando se construya la estructura de la base de datos. Así,

agregar una nueva dimensión o cambiar las vistas deseadas, puede ser engorroso y

costoso. Algunos MDDBs requieren un recargue completo de la base de datos cuando

ocurre una reestructuración. En la Figura No. 11, se muestra una vista multidimensional

de una base de datos.

 

Figura No. 11

 

       Nuevas dimensiones

Una limitación de un RDBMS y un MDDB, es la carencia de soporte para tipos de

datos no tradicionales como imágenes, documentos y clips de video/ audio. Si se necesita

estos tipos de objetos en un Data Warehouse, se debe buscar un DBMS relacional-objeto.

Por su enfoque en los valores de datos codificados, la mayor parte de los sistemas de

bases se acomodan a estos tipos de información, sólo con extensiones basadas en ciertas

referencias, tales como indicadores de archivos que los contienen. Muchos RDBMS

almacenan los datos complejos como objetos grandes binarios (BLOBs). En este formato,

estos no pueden ser indexados, clasificados, o buscados por el servidor.

 

Los DBMS relacional-objeto, de otro lado, almacenan los datos complejos como

objetos nativos y soportan las grandes estructuras encontradas en un ambiente orientado a

objetos. Estos sistemas de base de datos naturalmente acomodan no sólo tipos de

información especiales sino también los métodos de procesamiento que son únicos para

cada uno de ellos. Pero una desventaja del enfoque relacional-objeto, es que la

encapsulación de los datos dentro de los tipos especiales, requiere de operadores

especializados para que hagan búsquedas simples previamente. La selección del DBMS

está también sujeta al servidor de hardware que se usa. Los RDBMS, ofrecen versiones

que soportan operaciones paralelas. El software paralelo divide consultas, uniones a través

de procesadores múltiples y corre estas operaciones simultáneamente para mejorar el

rendimiento. Se requiere el paralelismo para el mejor desempeño en los servidores MPP

grandes y SMP agrupados. No es aún una opción con MDDBS o DBMS relacional-objeto.

 

       Combinación de la arquitectura con el sistema de gestión de base de datos

Para seleccionar la combinación correcta de la arquitectura del servidor y el DBMS,

primero se debe comprender los requerimientos comerciales de la compañía, la población

de usuarios y las habilidades del personal de soporte. Las implementaciones de los Data

Warehouse varían apreciablemente de acuerdo al área. Algunos son diseñados para

soportar las necesidades de análisis específico para un solo departamento o área funcional

de una organización, tales como finanzas, ventas o mercadeo. Las otras implementaciones

reúnen datos a través de toda la empresa para soportar una variedad de grupos de

usuarios y funciones. Por regla general, a mayor área del depósito, se requiere mayor

potencia y funcionalidad del servidor y el DBMS.

 

Los modelos de uso de los Data Warehouse son un factor. Las consultas y vistas de

reportes preestructuradas satisfacen a los usuarios informáticos, mientras que hay menos

demandas sobre el DBMS y la potencia de procesamiento del servidor. El análisis

complejo, que es típico de los ambientes de decisión-soporte, requiere más poder y

flexibilidad de todos los componentes del servidor. Las búsquedas masivas de grandes

Data Warehouse favorecen el paralelismo en las bases de datos y el servidor.

 

Los ambientes dinámicos, con sus requerimientos siempre cambiantes, se adaptan

mejor a una arquitectura de datos simple, fácilmente cambiable (por ejemplo, una

relacional altamente normalizada), antes que una estructura intrincada que requiere una

reconstrucción después de cada cambio (por ejemplo, una multidimensional).

 

El valor de los datos frescos, indica cuán importante es para el Data Warehouse

renovar y cambiarlos. Los grandes volúmenes de estos que se refrescan a intervalos

frecuentes, favorecen una arquitectura físicamente centralizada para soportar una captura

de datos eficiente y minimizar el tiempo de transporte de los datos.

 

Un perfil de usuario debería identificar quiénes son los usuarios de su Data

Warehouse, dónde se ubican y cuántos soporta. La información sobre cómo cada grupo

espera usar los Data Warehouse, ayuda en el análisis de los diversos estilos de uso.

Conocer la ubicación física de sus usuarios ayuda a determinar cómo y a qué área

necesita distribuir el Data Warehouse. Una arquitectura por niveles podría usar servidores

en el lugar de las redes de área local. O puede necesitar un enfoque centralizado para

soportar a los trabajadores que se movilizan y que trabajan en el depósito desde sus

computadores portátiles.

 

El número total de usuarios y los modelos de conexión determinan el tamaño de

servidores de depósito. Los tamaños de memoria y los canales de entrada y salida (I/O)

soportan el número previsto de usuarios concurrentes bajo condiciones normales, así

como también en las horas pico de su organización. Finalmente, se factoriza la

sofisticación del personal de soporte. Los recursos de los sistemas de información que

están disponibles dentro de su organización, limitan la complejidad o sofisticación de la

arquitectura del servidor. Sin el personal especializado interno o consultores externos, es

difícil crear y mantener satisfactoriamente una arquitectura que requiere paralelismo en la

plataforma del servidor.

 

       Planes de expansión 

Como el depósito evoluciona y los datos que contiene son más accesibles, los

empleados externos al depósito descubren el valor de la información. Al enlazar el Data

Warehouse a otros sistemas (tanto internos como externos a la organización), se comparte

información con otras entidades comerciales con poco o sin desarrollo. Los mensajes de

correo electrónico, servidores Web y conexiones Intranet/Internet, entregan listas por

niveles a proveedores o según la condición, a socios de negocio.

 

Como los Data Warehouse crecen en sofisticación y uso, los datos acumulados

dentro de una empresa llegarán a estar organizados, interconectados, accesibles y, en

general, disponibles a más empleados. El resultado es la obtención de mejores decisiones

en el negocio, oportunidades y claridad de trabajo.

 

2.2.4. 3.2.4.      Confiabilidad de los datos 

Los datos "sucios" son peligrosos. No importa cómo esté diseñado un programa o

cuán hábilmente se use. Si se alimenta mala información, se obtienen resultados

incorrectos o falsos. Desdichadamente, los datos que se usan satisfactoriamente en las

aplicaciones de línea comercial operacionales algunos son basura en lo que concierne a la

aplicación Data Warehouse.

 

Los datos "sucios" se presentan al ingresar información en una entrada de datos o

de otras causas. Cualquiera que sea, los datos sucios dañan la credibilidad de la

implementación del depósito completo. Afortunadamente, las herramientas de limpieza de

datos son de gran ayuda. En algunos casos, se crea un programa de limpieza efectivo. En

el caso de bases de datos grandes, imprecisas e inconsistentes, el uso de las herramientas

comerciales es casi obligatorio.

 

Decidir qué herramienta usar es importante y no solamente para la integridad de los

datos. Si se equivoca, se podría malgastar semanas en recursos de programación y costos

de herramientas.

 

       Limpieza de los datos

La limpieza de datos sucios es un proceso multifacético y complejo. Los pasos a

seguir son los siguientes:

 

       Análisis de datos corporativos para descubrir inexactitudes, anomalías y otros

problemas.

       Transformación de datos para asegurar que sean precisos y coherentes.

       Asegurar la integridad referencial, que es la capacidad del Data Warehouse,

para identificar correctamente al instante cada objeto del negocio, tales como un

producto, un cliente o un empleado.

       Validación de datos que usa la aplicación del Data Warehouse para realizar las

consultas de prueba.

       Producir la metadata, una descripción del tipo de datos, formato y el

significado relacionado al negocio de cada campo.

       Finalmente, viene el paso crucial de la documentación del proceso completo

para que se pueda ampliar, modificar y arreglar los datos en el futuro con más

facilidad.

 

En la práctica, se realizan múltiples pasos como parte de una operación única o

cuando se usa una herramienta. En particular, limpiar los datos y asegurar la integridad

referencial son procesos interdependientes. Las herramientas comerciales ayudan en cada

uno de estos. Sin embargo, es posible escribir programas propios para hacer el mismo

trabajo.

 

Los programas de limpieza de datos no proporcionan mucho razonamiento, por lo que

las compañías necesitan tomar decisiones en forma manual, basados en información

importante y reportes de auditoria de datos. Cada vez que se carga un nuevo conjunto de

elementos, la limpieza de estos comúnmente constituye cerca del 25 por ciento de lo que

es un proceso de cuatro semanas.

 

       Tipos de limpieza de datos  

       Limpieza de datos moderada. Si se decide no programar funciones de

limpieza de datos o contratar un consultor para hacer el trabajo, se puede inhibir de

la compra de una herramienta específica para esa tarea. El software de gestión del

Data Warehouse es suficiente para limpiar y validar según los propósitos. Muchos

proyectos de Data Warehouse usan productos para varias tareas de gestión de Data

Warehouse, que incluyen:

 

o o        Extracción de los datos desde las bases de datos operacionales.

o o        Preparación de los datos para cargarlos en una base de datos del

depósito.

o o        Administración de la metadata.

 

       Limpieza de datos intensa. Para trabajos de limpieza intensos, se consideran

herramientas que se desarrollan para esas tareas.

 

       Enfoque Top-Down. Este es un enfoque en el que el cliente propone las reglas

para limpiar los datos. Esta es una estrategia directa, donde se impone los

conocimientos sobre el negocio en los datos.

 

Por ejemplo:

o o        ¿ Se trata una serie de concesiones de una empresa X como un cliente

único con direcciones múltiples?

o o        Para los propósitos del Data Warehouse, ¿tiene sentido sustituir una

dirección central única para las diferentes direcciones de las concesiones?

o o        O, ¿Se prefiere tratar las ubicaciones de las concesiones como clientes

completamente diferentes?

o o        Esta decisión determina cómo se agrega o consolida estos registros y si se

tratan las diferentes direcciones como excepciones.

 

La desventaja principal del enfoque top-down es que se tiene que conocer, o

se deducen las reglas del negocio y de la limpieza de datos.

 

       Enfoque Bottom-Up. Este enfoque, analiza los datos por caracter y

automáticamente emergen los modelos y las reglas del negocio. Generalmente,

proporciona un diseño de estos que normaliza, condiciona y consolida. Este enfoque

deja pocas excepciones que se manejan manualmente y el proceso consume menos

tiempo.

 

Al igual que el enfoque top-down toma en cuenta las relaciones comerciales

que no son obvias a partir de los datos, tales como fusiones y adquisiciones que

tienen lugar desde que fueron creados los datos. Incide exclusivamente sobre la

limpieza de los datos, comenzando desde los archivos básicos. No extrae los datos

desde bases de datos operacionales, carga los datos en la base de datos del

depósito, duplica y sincroniza los datos o administra la metadata.

 

2.2.5. 3.2.5.      Factores decisivos para decidir el desarrollo de un Data Warehouse

 

Los datos sucios son un serio peligro para el éxito de un proyecto de Data

Warehouse. Dependiendo del alcance del problema, simplemente no es posible dirigirlo

rápidamente y abaratarlo.

 

Los principales factores son:

       El tiempo que toma la programación interna

       El costo de las herramientas

 

Los gerentes de proyectos de Data Warehouse evaluan el problema con realismo,

los recursos internos disponibles que distribuyen y seleccionan la solución que se adapta a

la planilla y presupuesto del proyecto, o se modifica la planilla y el presupuesto y se

soluciona el problema.

 

2.2.6. 3.2.6.      Etapas para la construcción de un Data Warehouse 

         Crear la Base de Datos de Data Warehouse

 

Luego de identificadas las dimensiones y los factores clave para la creación del Data

Warehouse, se crea una base de datos denormalizada la cual almacena información que

posteriormente se carga basada en los datos de la base de datos real, para después

realizar las consultas necesarias por medio de las consultas generadas del Data

Warehouse.

 

       Tipos de Diagramas 

Existen dos tipos de diagramas en los que se representa o define la estructura en la

que se desea realiza el Data Warehouse, para faciliar la consulta de la información y no

tener limintaciones a la normalización existente en los sistemas operacionales. Estos

diagramas son conocidos como:

Snowflake  

       Diagrama de Estrella

 

o o        Snowflake

Es una extensión de un diagrama estrella de una o más dimensiones definidas por

múltiples tablas. Un esquema snowflake solamente se une a la tabla principal (fact table)

las dimensiones primarias. Este diagrama obtiene su nombre de la imagen que resulta de

agregar extensiones de tablas jerárquicas al diagrama de estrella.

Por ejemplo la jerarquía de la tabla productos. Esta tiene una marca, Tiene una

categoría y este un departamento.

 

Figura No. 12

 o o                          Diagrama de Estrella

Este diagrama se usa para resolver los problemas que los negocios tienen ante un modelo

normalizado.

         El centro del diagrama es una tabla llamada Fact Table o tabla principal que

contiene los indicadores clave identificados durante el proceso de análisis y que

contienen combinación de información de objetos y tiempo. Los indicadores son los

atributos y los objetos y tiempos la llave primaria.

 

       A los alrededores tiene las dimensiones que contienen información de los objetos y

tiempo.

 

El diagrama estrella es implementado usando tecnología de base de datos

relacional.

 

Figura No. 13

 

Diagrama de Estrella, Características de las Dimensiones

       Que contengan llave primaria.

       Debe tener una relación de uno a muchos con la Fact Table.

       Debe contener por lo menos una columna de descripciones.

       Contener otras columnas de atributos que sean útiles para los niveles de

agregación.

       Contener un número limitado de filas que se incrementen lentamente en el

tiempo.

 

Diagrama de Estrella, Características de la Fact Table

       Contiene una llave primaria compuesta de las llaves foráneas de las tablas

dimensionales.

       Contiene columnas numéricas adicionales.

       No es necesario que exista ninguna otra combinación de llaves foráneas.

       Contiene un gran número de filas.

 

Continuando con la estructura del Data Warehouse, el siguiente paso sería la

transformación de los datos.

 

Figura No. 14

 

o o        Transformación de los datos

Para la transformación de los datos se utiliza una herramienta que facilita dicha

transformación y que cumple con las siguientes características:

 

       Es una aplicación para la consolidación de datos provenientes de una gran

variedad de orígenes heterogéneos y carga los datos en el Data Warehouse.

       Permite acceder otras aplicaciones que pueden ser usadas como origen o destino

de los datos.

       Facilita el importar, exportar y transformar datos de orígenes heterogéneos no

solamente del mismo ambiente.

       Soporta el 100% de cada origen y destino de los datos.

       Provee una extensa arquitectura para vendedores independientes de software,

consultores y clientes.

Figura No. 15

 

       Construcción del Cubo

Siguiendo con las actividades de creación del Data Warehouse, ya que se ha

importado la información de la base de datos normalizada a la base de datos

denormalizada, ahora se crea del Cubo.

 

Que es un cubo?

Como una definición de cubo diremos que es el objeto central de los datos, el cual

contiene información en una estructura multidimensional. Cada cubo es definido por un

conjunto de dimensiones y medidas.

 

       Estructura Multidimensional del cubo

La información de negocios, necesita tomar forma de pregunta. La respuesta a

estas preguntas provee una entrada a la dirección estratégica del negocio. Los negocios

necesitan una vista multidimensional para responder a preguntas complejas como:

 

       ¿Cuál fue el volumen de ventas de cerezas en un lugar determinado durante el

segundo trimestre?

       ¿Qué producto tiene el mayor volumen de ventas en cada lugar durante el cuarto

trimestre?

 

Hay muchas preguntas que se realizan sin que estén basadas en medidas. Aquí es

cuando la multidimensionalidad no es la primera opción si el negocio hace preguntas que

no son respondidas basadas en medidas. Algunas preguntas de este tipo son:

 

       ¿Quién fue el primer empleado contratado durante el primer trimestre del año

pasado?

       ¿Qué productos estan agregados al inventario este año?

 

Estas preguntas no son contestadas con medidas. Para contestarlas es necesario

regresar a consultas en donde se accesen las tablas dimensionales.

 

       Construcción de dimensiones

         Definición de dimensiones. Una dimensión de un cubo es una vista jerárquica de

la información en la Fact table o tabla principal.

o o        La información de los cubos esta basada en dimensiones.

o o        El usar dimensiones permite hacer un análisis drill-down (iniciando del

nivel más alto y bajando a detalle de nivel en nivel).

 

       Dimensiones privadas. Las dimensiones privadas son las que son creadas ya

dentro de un cubo.

o Se definen en el momento de la creación del cubo.

o Están almacenadas en la librería de cada cubo.

 

       Dimensiones compartidas. Estas dimensiones son creadas independientemente

de algún cubo en particular.

o Son almacenadas en el Data Warehouse.

o Están compartidas para uno o más cubos.

o Son usadas para estandarizar algunas medidas del negocio, asegurar la

consistencia en varios cubos.

 

       Diseño y construcción de agregaciones

 Qué es una agregación?

Son agregaciones los datos precalculados que permiten una rápida respuesta en el

momento de la consulta. Almacenando datos precalculados el servidor se recupera la

información para estos cálculos ni hacer cualquier cálculo numérico. El uso de

agregaciones es la base para una respuesta rápida en los sistemas OLAP.

 

Los cubos son la forma de que se almancenan las agregaciones en los sistemas

OLAP. Las dimensiones significan consultas al cubo. Las agregaciones están almacenadas

en la intersección de las dimensiones. Cada intersección (llamada celda) almacena un

simple valor.

 

Para realizar una agregación es indispensable se considera tanto el espacio en

disco como la explosión de los datos.

 

       Métodos de almacenamiento del cubo  

Los cubos son almacenados en formatos multidimensionales, en una estructura

estándar relacional o en una combinación de ambos. El método de almacenamiento que se

escoja, influye en los requerimientos y presentación del cubo. Dentro de los métodos de

almacenamiento del cubo se encuentran los siguientes:

 

       Rolap (Relational Online Analitical Processing)

       Molap (Multidimentional Online Analitical Processing)

       Holap (Hybrid Online Analitical Processing)

 

Rolap

Es un método de almacenamiento que guarda las agregaciones en tablas

relacionales, no requiere espacio extra para almacenar los datos, causa una respuesta

lenta en consultas a comparación de Molap y Holap. Es la mejor opción de

almacenamiento para datos que no son frecuentemente consultados. Algunas de sus

características son:

       Las tablas son creadas en un RDBMS.

       La carga de datos es por medio de INSERT INTO.

       No se mueven datos del servidor OLAP.

       Los índices se crean automáticamente.

       Se usanS agregaciones ya existentes.

       Ofrece soporte para varios manejadores de bases de datos. (SQL Server,

Oracle, Jet, ODBC).

 

Figura No. 16

 Molap

Es un método de almacenamiento que guarda los datos en una estructura

multidimensional. Ofrece el mejor desempeño en cuanto a consultas, porque su estructura

contiene las agregaciones y los datos base.Consume mucho espacio de almacenamiento

porque los cubos con muchas agregaciones se hacen demasiado grandes.

 

Figura No. 17

 

Holap

Esta es una combinación de Molap y Rolap. Las agregaciones son almacenadas

como la estructura Molap. Los datos base quedan en las tablas relacionales. Las consultas

que solo accesan datos precalculados son tan rápidos como la estructura Molap. Las

consultas que necesitan bajar a mucho nivel de detalle son lentas como la estructura

Molap pero son rápidos como la estructura Rolap. Los cubos Holap son más pequeños que

los Molap ya que solamente almacena las agregaciones y no los datos base.

 

Figura No. 18

 

       Proceso de un cubo

Después de crear el cubo y definido las agregaciones, se hace la carga del cubo con

las agregaciones a la base de datos. Esta se realiza por medio de llamadas a procesos, los

cuales realizan la carga completa de los datos. Cuando se procesa un cubo, se llama al

almacén de la base de datos y las agregaciones que estén definidas en estas dimensiones.

Las agregaciones luego son almacenadas en la estructura del cubo o en bases

relacionales. Este proceso consume mucho tiempo, basado en las cantidades de los datos

y cálculos (agregaciones).

¿Cuándo actualizar la información?

       Cuando datos existentes son borrados.

       Cuando las agregaciones son recalculadas y almacenadas.

       Si los datos base han cambiado.

El cubo puede ser usado mientras este es actualizado.

 

2.3. 3.3.               Implementación  

En esta fase, el proyecto de Data Warehouse tiene asignado el liderazgo adecuado, así

como, los recursos humanos, tecnológicos y el presupuesto apropiado. Sin embargo, se evaluan

otros aspectos, como el desarrollo de un proyecto en su totalidad o por fases y además, se

diferencia el tipo de proyecto a realiza.

  

2.3.1. 3.3.1.      Elementos a considerar en la implementación

 

       Proyecto total o proyecto en fases. Es viable el desarrollo de un proyecto en

fases que produzcan resultados a corto plazo que el uno que entregue resultados al

término de varios años. Por ello, este debe estar centrado en un área o un proceso.

 

       Modelo lógico de datos. Debe tener un alcance más alto y cubrir todas las áreas

de interés, así como los procesos más estratégicos de cada una de ellas. Ejemplo: Se

cubren las áreas de mercadeo, crédito y comercialización y los procesos de

segmentación, record para retención, para crédito y gestión de clientes, productos y

canales de ventas.

 

       Proyecto especializado o proyecto base. Se decide qué tipo de proyecto, es

algo complicado. Uno especializado soporta directamente un proceso específico, por

ejemplo: retención de clientes. Uno base entrega capacidad genérica de análisis a

todos los usuarios que tengan acceso al Data Warehouse, pero no tiene, entre sus

funcionalidades, la solución de un problema específico o el soporte especializado de

un proceso como tal. Un proyecto base es más económico y fácil de acabar que uno

especializado, más costoso y difícil de terminar.

 

2.3.2. 3.3.2.      Estrategias para el proceso de implementación  

Para el proceso de implementación, se definen los siguientes pasos:

       Se identifica el problema en el cual el uso estratégico de la información detallada,

permite conseguir una solución para generar una ventaja competitiva o un ahorro de

costos. Ejemplo: Un problema puede ser la ausencia de un modelo para estudios de

retención de clientes.

 

       Se define el modelo lógico de datos a implementar para resolver el problema

planteado. Ejemplo: Se puede dar un modelo cuando se presenta al usuario la

información en términos de dimensiones (clientes, productos, canales de ventas,

promociones, adquirientes, etc) básicas del modelo de datos y hechos que se registran

para estas dimensiones (medidas de ventas, de costos, de producción, de facturación,

de cartera, de calidad, de servicio, etc.).

 

       Se reunen los datos que poblan ese modelo lógico de datos.

 

       Se toman iniciativas de complementación de información que aseguran la calidad

de los datos requeridos y se completa el modelo de datos. Estas definiciones estan

acompañadas de un servidor apropiado para el Data Warehouse, así como elementos

de comunicaciones, nodos cliente, el manejador de la base de datos del Data

Warehouse y otros hardware y software requeridos para la implementación del

proyecto.

 

2.3.3. 3.3.3.      Estrategias en la implementación 

Se plantean las siguientes:

 

       Se define el mejor diseño físico para el modelo de datos. El diseño físico esta

orientado a generar buen rendimiento en el procesamiento de consultas, a diferencia

del modelo lógico que está orientado al usuario y a la facilidad de consulta.

 

       Se definen los procesos de extracción, filtro, transformación de información y carga

de datos que se implementan para poblar ese modelo de datos.

 

       Se definen los procesos de administración de la información que permanece en el

Data Warehouse.

 

       Las formas de consultas a la información del Data Warehouse que se le

proporcionan al usuario. Para ésto, se considera la necesidad de resolver un problema

y la potencia de consulta.

 

       Se completa el modelo de consulta base, relativo al área seleccionada.

 

       Implementar los procesos estratégicos del área de trabajo, es decir, implementar

herramientas especializadas de records, herramientas especializadas para inducción

de conocimiento (Data Mining), etc.

 

       Completar las áreas de interés, en forma similar a lo descrito anteriormente.

 

2.4. 3.4.               Evaluación   

2.4.1. 3.4.1.      Evaluación de rendimiento de la inversión  

Cuando se evalúan los costos, el usuario del Data Warehouse no tiene el contenido

de los costos en mente, pero las preguntas mínimas que comienzan a hacerse son las

siguientes:

 

       ¿Qué clases de costos excedieron el presupuesto en más del 10% en cada uno de

los 12 meses pasados?

 

       ¿Se aumentaron los presupuestos en más de 5% para cualquier área dentro de los

últimos 18 meses?

 

       ¿Cómo especificar las clases de gastos entre diferentes departamentos? ¿Entre

divisiones? ¿A través de las regiones geográficas?

 

       ¿Cómo tener márgenes de operación sobre los dos últimos años en cada área de

negocio? Donde han disminuido los márgenes, ¿se han incrementado los costos?

 

Con frecuencia, los aspectos realmente importantes identificados por una gestión

mayor, tienen un valor agregado, en el que se sabe si tuvieron la información que se

estaba buscando, lo que significaría una mejora de por ejemplo, las ventas en 0.5% a 1% -

que, si su operación estuvo por los millones de quetzales en un año, resulta en cientos de

millones de quetzales. En algunos casos, el costo del depósito inicial se recobra en un

período de 6 a 8 meses. Al hacerse preguntas de este tipo, los usuarios comienzan a

identificar las áreas en la que los costos han aumentado o disminuido significativamente y

pueden evaluar cada una de estas áreas con más detalle.

 

Costos y beneficios

Se identifican diversos costos y beneficios en la elaboración de un proyecto de

construcción de un Data Warehouse, tales como:

       Costos

o o        Costos preliminares

             Planificación

             Diseño

             Modelamiento / Ingeniería de Información

o o        Costos iniciales

                 Plataforma de hardware

                 Software de base de datos

                 Herramientas de transferencia y limpieza de datos

o o        Costos en procesamiento

                 Mantenimiento de datos

                 Desarrollo de aplicaciones

                 Capacitación y soporte

 

                     Beneficios

o o        Beneficios Tácticos

         Impresión y emisión de reporte reducido

         Demanda reducida para consultas de clientes

         Entrega más rápida de información a los usuarios

o o        Beneficios Estratégicos (Potencialidad)

         Aplicaciones y herramientas de acceso para los usuarios finales

         Decisiones con mayor información

         Toma de decisiones más rápida

         Capacidad de soporte a la información organizacional

 

2.4.2. 3.4.2.      Beneficios a obtener 

       Para la Empresa

El Data Warehouse hace lo posible por aprovechar el valor potencial enorme de los

recursos de información de la empresa y volver ese valor potencial en valor verdadero.

 

       Para los Usuarios

El Data Warehouse extiende el alcance de la información para que se acceda

directamente en línea, lo que a la vez contribuye en su capacidad para operar con mayor

efectividad las tareas rutinarias o no. Los usuarios del Data Warehouse acceden a una

riqueza de información multidimensional, presentado coherentemente como una fuente

única confiable y disponible a ellos por medio de sus estaciones de trabajo. Los usuarios

usan las herramientas familiares, hojas de cálculo, procesadores de textos y software de

análisis de datos y análisis estadístico para manipular y evaluar la información obtenida

desde el Data Warehouse.

       Para la organización en tecnologías de información

El Data Warehouse enriquece las capacidades del usuario autosuficiente y hace lo

factible y ofrece nuevos servicios a los usuarios, sin interferir con las aplicaciones

cotidianas de producción. La pugna constante por resolver las necesidades de usuarios

que piden acceso a los datos operacionales, finaliza con la implementación de un Data

Warehouse. La mayoría de los usuarios no necesita accesar más a los datos actuales,

porque ellos tienen información más útil disponible desde el Data Warehouse.

 

Un Data Warehouse aumenta el valor de las inversiones en tecnologías de

información, en aplicaciones y bases de datos operacionales. Como estas bases de datos

alimentan información, al evolucionar el Data Warehouse, llegan a ser imprescindibles no

solamente para las operaciones diarias, sino además como la fuente de información del

negocio de amplio rango.

 

CAPITULO IV 

3. 4.      SOFTWARE EN UN DATA WAREHOUSE

 

3.1. 4.1.               Herramientas de consulta y reporte  

Existe una gran cantidad de poderosas herramientas de consulta y reporte en el mercado.

Algunos proveedores ofrecen productos que permiten tener más control sobre qué procesamiento

de consulta es hecho en el cliente y cual en el servidor. Las más simples de estas son productos

de este tipo. Ellos proporcionan desde pantallas gráficas a generadores SQL (o más preciso,

generadores de acceso-llamada a bases de datos).

 

Más que aprender SQL (Structured Query Language) o escribir un programa para acceder a

la información de una base de datos, las herramientas de consulta al igual que la mayoría visuales,

permiten apuntar a los menús y botones para especificar los elementos de datos, condiciones,

criterios de agrupación y otros atributos de una solicitud de información. La herramienta de

consulta genera entonces un llamado a una base de datos, extrae los datos pertinentes, efectúa

cálculos adicionales, manipula los datos si es necesario y presenta los resultados en un formato

claro.

 

Las consultas y los pedidos de reporte se almacenan para trabajos subsiguientes, como

está o con modificaciones. El procesamiento estadístico se limita comúnmente a promedios,

sumas, desviaciones estándar y otras funciones de análisis básicas. Aunque las capacidades

varían de un producto a otro, las herramientas de consulta y reporte son más apropiadas cuando

se necesita responder a la pregunta ¿"Qué sucedió"? (Ejemplo: ¿"Cómo comparar las ventas de

los productos X, Y y Z del mes pasado con las ventas del presente mes y las ventas del mismo

mes del año pasado?").

 

Para hacer consultas más accesibles a usuarios no técnicos, existen productos que ofrecen

interfaces gráficas para seleccionar, arrastrar y pegar. Lo más avanzado de estos orientan hasta

las consultas que tienen sintaxis mala o que devuelven resultados imprevistos. El acceso a los

datos ha mejorado también con las nuevas versiones de estos productos y los vendedores ya

instalan manejadores (drivers) estándares, hasta fuentes comerciales.

 

En general, los administradores de Data Warehouse que usan estos tipos de productos,

estan dispuestos a ocupar su tiempo para resolver las tareas de estructuración, como

administración de bibliotecas y directorios, instalación de software de conectividad, establecer

nombres similares en Inglés y precalcular "campos de datos virtuales". Una vez que se han creado

las pantallas SQL (Structured Query Language), se desarrolla un conjunto de consultas y reportes

estándares, aunque algunos productos ofrecen librerías de plantillas prediseñadas y reportes

predefinidos que se pueden modificar rápidamente.

 

3.2. 4.2.      Herramientas de base de datos multidimensionales / OLAP  

Los generadores de reportes tienen sus limitaciones cuando los usuarios finales necesitan

más que una sola, una vista estática de los datos, que no sean sujeto de otras manipulaciones.

Para estos usuarios, las herramientas del procesamiento analítico en línea (OLAP - On Line

Analytical Processing), proveen capacidades que contestaría "¿qué sucedió?" al analizar por qué

los resultados están como están.

 

Las primeras soluciones OLAP estan basadas en bases de datos multidimensionales

(MDDBS). Un cubo estructural (dos veces un hipercubo o un arreglo multidimensional) almacena

los datos para que se manipulen intuitivamente y claramente ver las asociaciones a través de

dimensiones múltiples. Los productos pioneros soportan directamente las diferentes vistas y las

manipulaciones dimensionales requeridas por OLAP.

 

3.2.1. 4.2.1.      Limitaciones del enfoque de bases de datos multidimensionales:

 

       Las nuevas estructuras de almacenamiento de datos requieren bases de datos

propietarias. No hay realmente estándares disponibles para acceder a los datos

multidimensionales. Los proveedores, ven esto como una oportunidad para crear

normas para editar APIs, propiciando herramientas terceristas y estableciendo

asociaciones estratégicas. Muchas de estas herramientas de consulta y de soluciones

Data Mining soportan directamente formatos MDDB comunes. Algunas herramientas

cliente / servidor, se sitúan sobre la parte superior de un Data Warehouse

multidimensional y soportan el acceso dinámico y la manipulación de los datos.

 

       La segunda limitación de un MDDB concierne al desarrollo de una estructura de

datos. Las compañías generalmente almacenan los datos de la empresa en bases de

datos relacionales, lo que significa que se extraen, transforman y cargan estos datos

en el hiper cubo. Este proceso es complejo y consume tiempo, pero nuevamente, los

proveedores están investigando la forma de solucionarlos. Las herramientas de

extracción de datos y otras automatizan el proceso, trazando campos relacionales en la

estructura multidimensional y desarrollando el MDDB sobre la marcha.

 

Algunos proveedores ofrecen ahora la técnica OLAP relacional (Relational On Line

Analytical Processing - ROLAP), que explora y opera en el Data Warehouse directamente

usando llamadas SQL (Structure Query Language) estándares. Las herramientas de

pantallas permiten retener los pedidos multidimensionales, pero el motor ROLAP

transforma las consultas en rutinas SQL. Entonces se reciben los resultados tabulados

como una hoja de cálculo multidimensional o en alguna otra forma que soporte rotación y

reducción.

 

Así como la extracción de los datos, el desarrollo y evolución de la estructura MDDB

puede cambiarse. Los administradores ROLAP afrontan algunas veces las tareas

(agobiantes) de desarrollar las rutinas SQL para agregar e indexar los datos ROLAP, así

como, aseguran la traducción correcta de los pedidos multidimensionales en la ventana de

comandos SQL.

Los defensores de ROLAP argumentan que se usan estándares abiertos (SQL) y

que se esquematizan (nivel de detalle) los datos para hacerlos más fácilmente accesibles.

Por otra parte, afrman que una estructura multidimensional nativa logra mejor desempeño y

flexibilidad, una vez que se desarrolla el almacén de los datos.

 

Lo bueno es que estas tecnologías evolucionan rápidamente y/o proveen una pronta

solución OLAP. Los retos administrativos y de desarrollo de OLAP, a diferencia de las

encontradas con las herramientas de consulta y reporte, son generalmente más complejos.

Definiendo el OLAP y el software de acceso a los datos, se requiere un claro entendimiento

de los modelos de datos de la corporación y las funciones analíticas requeridas por

ejecutivos, gerentes y otros analistas de datos.

 

El desarrollo de productos comerciales aminora los problemas, pero OLAP es

raramente una solución clave. La arquitectura permite el soporte a su fuente de datos y

requerimientos. Pero una vez que se establece un sistema OLAP, el soporte al usuario final

es mínimo.

 

Los usuarios de estos productos deciden sobre si los datos del procesamiento

analítico en línea, deben almacenarse en bases de datos multidimensionales

especialmente diseñadas o en bases de datos relacionales. Esto depende de las

necesidades de la organización.

 

3.3. 4.3.               Sistemas de apoyo a las decisiones

 3.3.1. 4.3.1.      Sistemas de soporte para la toma de decisiones (DSS)

Este tipo de sistemas tienen como finalidad la toma de decisiones mediante la

generación y evaluación sistemática de diferentes alternativas o escenarios de decisión

mediante el empleo de modelos y herramientas. Estos sistemas se usan como apoyo

durante las primeras fases del modelo de toma de decisiones, y obtienen información que

revele los elementos clave de los problemas y las relaciones entre ellos. También

identifican, crean y comunican cursos de acción disponibles y alternativas de decisión.

 

Características de los sistemas de soporte para la toma de decisiones

       Interactividad: Sistema que interactua en forma amigable y con respuestas a

tiempo real con el encargado de tomar decisiones.

       Tipo de decisiones: Apoya el proceso de toma de decisiones estructuradas y

no estructuradas.

       Frecuencia de Uso: Tiene una utilización frecuente por parte de la

administración media y alta para el desempeño de su función.

       Variedad de usuarios: Es empleado por usuarios de diferentes áreas

funcionales como ventas, producción, administración, finanzas y recursos

humanos.

       Flexibilidad: Permite acoplarse a una variedad determinada de estilos

administrativos.

       Desarrollo: Permite que el usuario desarrolle de manera directa modelos de

decisión sin la participación operativa de profesionales.

       Interacción ambiental: Permite interactuar con información externa como

parte de los modelos de decisión.

       Comunicación interorganizacional: Facilita la comunicación de información

relevante de los niveles altos hacia los niveles operativos.

       Acceso de base de datos: Tiene capacidad de acceder información de las

bases de datos corporativas.

       Simplicidad: Simple y fácil de aprender y utilizar por el usuario final.

 

3.3.2. 4.3.2.      Sistemas de información para ejecutivos (EIS)

 Estos sistemas apoyan el proceso de toma de decisiones de los altos ejecutivos de

una organización, presentan información relevante y usan recursos visuales y de fácil

interpretación, con el objetivo de mantenerlos informados. El objetivo fundamental de este

tipo de sistemas es el monitoreo y seguimiento por parte del ejecutivo de los factores

críticos del éxito del negocio.

 

Características de los sistemas de información para ejecutivos  

       Están diseñaos para cubrir las necesidades específicas y particulares de la

alta administración de la empresa.

       Extraen, filtran, comprimen y dan seguimiento a información crítica del

negocio.

       Implican que los ejecutivos pueden interactuar en forma directa con el sistema

sin el apoyo o auxilio de intermediarios.

       Es un sistema desarrollado con altos estándares en sus interfases hombre-

máquina, caracterizado por gráficas de alta calidad, información tabular y en forma

de texto.

       Accede información que se encuentra en línea, extrayéndola en forma directa

de las bases de datos de la organización.

 

3.3.3. 4.3.3.      Sistemas para la toma de decisiones en grupo (GDSS)

 

Estos sistemas cubren el objetivo de lograr la participación de un grupo de personas

durante la toma de decisiones en ambientes de anonimato y consenso, apoyando

decisiones simultáneas. Son sistemas interactivos los cuales facilitan la solución de

problemas no estructurados por un conjunto de tomadores de decisiones que trabajan

juntos como un grupo.

 

Características de los sistemas para la toma de decisiones en grupo

 

       Son sistemas diseñados especialmente para apoyar las decisiones en grupo.

       Su meta es apoyar el trabajo de los tomadores de decisiones.

       Es facil de aprender y de usar. Debe ser accesible para usuarios con

diferentes niveles de conocimiento computacional y de soporte de decisiones.

       Es específico o general. Es específico si se diseña para un tipo o clase de

problema, y es general si se diseña para tomar diversas decisiones

organizacionales.

       Contiene mecanismos para evitar el desarrollo de conductas negativas en el

grupo, como son los problemas de comunicación, estar de acuerdo con lo que dice

la mayoría.

       Motiva a todos los miembros del grupo a participar de manera activa.

 

3.3.4. 4.3.4.      Sistemas expertos de soporte para la toma de decisiones

(EDSS)

 

Son los sistemas que permiten cargar bases de datos de conocimiento integrados

por una serie de reglas de sentido común para que diferentes usuarios los consulten,

apoyan la toma de decisiones y la capacitación. Son sistemas computacionales interactivos

que permiten la creación de bases de conocimiento, las cuales una vez cargadas,

responden a preguntas, despejan y sugieren cursos de acción simulando el proceso de

razonamiento de un experto para resolver aproblemas en un área específica del

conocimiento humano.

 

También, permiten a los desarrolladores de sistemas colocar el contexto del negocio

alrededor de información diversa. Un uso típico de un EIS es facilitar al usuario la

recuperación y análisis de las métricas, de rendimiento de la organización. El precio de

esta facilidad de uso es que por lo general existen algunas limitaciones sobre las

capacidades analíticas disponibles con el sistema de información ejecutivo.

 

Además, muchas de las herramientas de consulta / reporte y

OLAP/multidimensional, se usan para desarrollar sistemas de información ejecutivos. El

concepto de sistema de información ejecutivo es simple: los ejecutivos no tienen mucho

tiempo, ni la habilidad en muchos casos, para efectuar el análisis de grandes volúmenes

de datos. El EIS (Executive Information Systems) presenta vistas de los datos

simplificados, altamente consolidados y mayormente estáticas.

 

3.4. 4.4.               Herramientas Data Mining

 Data Mining es una categoría de herramientas de análisis de consulta. En lugar de hacer

preguntas, se toma estas y se pregunta algo "interesante", una tendencia o una agrupación

peculiar. Este proceso extrae los conocimientos guardados o información predictiva desde el Data

Warehouse sin requerir pedidos o preguntas específicas. Es una tecnología de soporte para

usuario final, que extrae conocimiento útil y utilizable a partir de la información contenida en las

bases de datos de las empresas.

 

Los objetivos se desarrollan bajo lenguajes de ultima generación basados en la inteligencia

artificial. Las herramientas Mining usan algunas de las técnicas de computación más avanzadas

como:

       redes neurales.

       detección de desviación.

       modelamiento predictivo. y

       programación genética.

 

para generar modelos y asociaciones. Mining es un dato-conducido, no una aplicación conducida.

 

3.5. 4.5.               Elección de herramientas

 Hay algunas reglas obvias a seguir cuando se eligen herramientas de análisis. Estas se

combinan según las necesidades de los usuarios finales, capacidad técnica empresarial y la fuente

de datos existente.

 

       Si se elige un proveedor de depósito que además ofrece herramientas integradas,

probablemente se ahorrará un tiempo de desarrollo significativo al elegir un conjunto que sean

compatibles. De otro modo, se selecciona un conjunto que soporte su fuente de datos original.

Sin este, se debería optar por una solución OLAP relacional debido a que provee una

arquitectura abierta.

 

       Después que se ha seleccionado un conjunto de herramientas compatible con su fuente de

datos, se determina cuánto análisis necesita realmente.

 

              Si simplemente se necesita saber "cuánto" o "cuántos", será suficiente una

herramienta básica de consultas y reportes.

              Si requiere un análisis más avanzado que explique la causa y los efectos de las

ocurrencias y las tendencias, se debe buscar una solución OLAP.

              Las herramientas Data Mining sofisticadas requieren expertos en técnicas de

análisis de datos y se necesitan para pronósticos avanzados, clasificación y creación

del modelo.

 

       Como con cualquier tecnología, para el mejor desempeño de la compañía, opta por una

solución única o un conjunto de soluciones. El personal debe comprender los requerimientos

de tecnología, desarrollar soluciones que reúnan esos requerimientos y mantener y mejorar

efectivamente los sistemas.

Los software de negocio inteligentes son sólo herramientas. Todavía se necesita gerentes

y ejecutivos que capten los conocimientos derivados y tomen decisiones intuitivamente. En otras

palabras, estos requieren todavía inteligencia comercial propia.

 

 

En la siguiente tabla se definen los parámetros a tener en cuenta para la elección de las

herramientas adecuadas.

 

Elija la Herramienta adecuada

Tipo de Pregunta básica Modelo de Salida Usuario típico

Herramienta

Consulta y Reporte ¿Qué sucedió?

Reportes de ventas

mensuales; histórico de

inventarioe

Necesitan datos

históricos pueden tener

aptitud técnica limitada.

Procesamiento

analítico en línea

(OLAP)

¿Qué sucedió y por

qué?

Ventas mensuales vs.

Cambios de precio de los

competidores

Necesita ir de una visión

estática de los datos a

una dinámica

técnicamente astuta

Sistema de Información

Ejecutiva (SIE)

¿Qué necesito

conocer ahora?

Libros electrónicos;

Centros de comandos

Necesita información

resumida o de alto nivel

puede no ser

técnicamente astuto

Data mining¿Qué es interesante?

¿Qué podría pasar?Modelos predictivos

Necesita extraer la

relación y tendencias de

la data ininteligible

técnicamente astuto.

  

 

 

CAPITULO V 

4. 5.      IMPACTOS EMPRESARIALES   4.1. 5.1.               Procesos empresariales y decisiones empresariales.

Se consideran los beneficios empresariales potenciales de los siguientes impactos:

 

       Los Procesos de Toma de Decisiones son mejorados mediante la disponibilidad de

información. Decisiones empresariales se hacen más rápidas por gente más informada.

 

       Los procesos empresariales son optimizados. El tiempo perdido esperando por

información que finalmente es incorrecta o no encontrada, es eliminado.

 

       Conexiones y dependencias entre procesos empresariales son más claros y

entendibles. Secuencias de procesos empresariales son optimizados para ganar

eficiencia y reducir costos.

 

       Procesos y datos de los sistemas operacionales, así como los datos en el Data

Warehouse, son usados y examinados. Cuando los datos son organizados y

estructurados para tener significado empresarial, la gente aprende mucho de los

sistemas de información. Quedan expuestos posibles defectos en aplicaciones actuales,

siendo posible entonces mejorar la calidad de nuevas aplicaciones. Comunicación e

impactos organizacionales.

 

Apenas el Data Warehouse comienza a ser fuente primaria de información empresarial

consistente, los siguientes impactos pueden comenzar a presentarse:

       La gente tiene mayor confianza en las decisiones empresariales que se toman.

Ambos, quienes toman las decisiones como los afectados conocen que está basada en

buena información.

 

       Las organizaciones empresariales y la gente de la cual se compone queda

determinada por el acceso a la información. De esta manera, la gente queda mejor

habilitada para entender su propio rol y responsabilidades como también los efectos de

sus contribuciones; a la vez, desarrollan un mejor entendimiento y apreciación con las

contribuciones de otros.

 

       La información compartida conduce a un lenguaje común, conocimiento común, y

mejoramiento de la comunicación en la empresa. Se mejora la confianza y cooperación

entre distintos sectores de la empresa, viéndose reducida la sectorización de funciones.

 

       Visibilidad, accesibilidad, y conocimiento de los datos producen mayor confianza en

los sistemas operacionales.

 

4.2. 5.2.               Impactos técnicos de Data Warehouse

 Considerando las etapas de construcción, soporte del Data Warehouse y soporte de

sistemas operacionales, se tienen los siguientes impactos técnicos:

       Nuevas destrezas de desarrollo: Cuando se construye el Data Warehouse, el impacto

más grande sobre la gente técnica está dada por la curva de aprendizaje, muchas

destrezas nuevas se deben aprender, incluyendo:

 

         Conceptos y estructura Data Warehouse.

         El Data Warehouse introduce muchas tecnologías nuevas (Carga, Acceso de

Datos, Catálogo de Metadatos, Implementación de DSS/EIS ), y cambia la manera que

se usa la tecnología existente. Nuevas responsabilidades de soporte, nuevas

demandas de recursos y nuevas expectativas, son los efectos de estos cambios.

 

         Destrezas de diseño y análisis donde los requerimientos empresariales no son

posibles de definir de una forma estable a través del tiempo.

 

         Técnicas de desarrollo incrementan y son evolutivos.

 

         Trabajo en equipo cooperativo con gente de negocios como participantes activos

en el desarrollo del proyecto.

 

       Nuevas responsabilidades de operación: Cambios sobre los sistemas y datos

operacionales son examinados cuidadosamente para determinar el impacto que estos

cambios tienen sobre ellos, y sobre el Data Warehouse.

 

4.3. 5.3.               ¿Quiénes y para qué lo usan?

 Dadas las características de un sistema de Data Warehouse, la aplicación tiene variados

fines, en una diversidad de industrias. No obstante, en términos generales, se dice que su

aplicación más rica corresponde a entornos de empresas en los que se identifican grandes

volúmenes de datos, asociados a: cantidad de clientes, variedad de productos y cantidad de

transacciones. A continuación se presentan ejemplos de aplicaciones típicas.

 

       Comercio Minorista

En este comercio utilizan grandes sistemas de procesamiento paralelo masivo para acceder

a meses o años de historia transaccional tomada directamente en los puntos de venta de cientos, o

miles, de sucursales. Con esta información detallada se efectuan en forma más precisa y eficientes

actividades de compra, fijación de precios, manejo de inventarios, configuración de góndolas, etc.

Las promociones y las ofertas de cupones son seguidas, analizadas y corregidas. Modas y

tendencias son cuidadosamente administradas a efectos de maximizar utilidades y reducir costos

de inventario.

 

La existencia es reasignada por sucursales o regiones según ventas y tendencias. Estos

sistemas con capacidad de procesar gran cantidad de datos detallados permiten implementar

eficientemente prácticas de mercadería "en consignación", en esta modalidad la cadena minorista

paga al proveedor recién cuando los productos son vendidos y pasados por el lector de códigos de

barras (scanner) del punto de venta. Esta información detallada permite ejercer mayor poder de

negociación sobre los proveedores, dado que el comercio minorista puede llegar a saber más que

el fabricante sobre los productos: quién lo compra, dónde, cuándo, con que otros productos, etc.

 

Regularmente lo que más atrae de un Data Warehouse es la clase de información que se

obtiene al instante. Reguralmente se elige cualquiera y se dice exactamente cuanto se ha vendido

en un tiempo determinado, no en promedio, en cualquier región, distrito o sucursal. Se le facilita a

los proveedores que sepan más acerca de su producto. Proporciona ventaja competitiva.

 

                   Manufactura de Bienes de Consumo Masivo

 Las empresas de este sector necesitan hacer un manejo cada vez más ágil de la información

para mantenerse competitivas en la industria. Los Data Warehouse se utilizan para predecir la

cantidad de producto que se vende a un determinado precio y, por consiguiente, producir la

cantidad adecuada para una entrega "justo a tiempo". A su vez se coordina el suministro a las

grandes cadenas minoristas con inmensas cantidades de productos "en consignación", que no son

pagados hasta que estos productos son vendidos al consumidor final.

 

Las cadenas minoristas y proveedores utilizan el Data Warehouse para compartir

información, permitiéndole a las empresas de manufactura conocer el nivel de stock en las

góndolas y eventualmente hacerse responsables de la reposición de inventario de la cadena

minorista. Como es de esperar esto reduce fuertemente la intermediación. También se utilizan para

campañas de mercadeo, planificación de publicidad y promociones y se coordinan las ofertas de

cupones y promociones con las cadenas minoristas.

 

Las mayores aplicaciones del sistema son para mercadeo, ventas, mantenimiento, garantía y

diseño de productos. Permite mantener la existencia de partes más ajustados y mejorar las

condiciones de negociación con los proveedores de las mismas.

 

                   Transporte de Cargas y Pasajeros

 Se utilizan Data Warehouse para almacenar y acceder a meses o años de datos de clientes

y sistemas de reservas para realizar actividades de mercadeo, planeamiento de capacidad,

monitoreo de ganancias, proyecciones y análisis de ventas y costos, programas de calidad y

servicio a clientes.

Las empresas de transporte de cargas llevan datos históricos de años, de millones de

cargamentos, capacidades, tiempos de entrega, costos, ventas, márgenes, equipamiento, etc.. Las

aerolíneas utilizan sus Data Warehouse para los programas de viajeros frecuentes, para compartir

información con los fabricantes de naves, para la administración del transporte de cargas, para

compras y administración de inventarios, etc. Hacen un seguimiento de partes de repuesto,

cumplimiento con las regulaciones aeronáuticas, desempeño de los proveedores, seguimiento de

equipaje, historia de reservas, ventas y devoluciones de tickets, reservas telefónicas, desempeño

de las agencias de viajes, estadísticas de vuelo, contratos de mantenimiento, etc.

 

                   Telecomunicaciones   

Estas empresas utilizan el Data Warehouse para operar en un mercado crecientemente

competitivo, no regulado y global que, a su vez, atraviesa profundos cambios tecnológicos. Se

almacenan datos de millones de clientes: circuitos, facturas mensuales, volúmenes de llamados,

servicios utilizados, equipamiento vendido, configuraciones de redes, etc. así como también

información de facturación, utilidades, y costos son utilizados con propósitos de mercadeo,

contabilidad, reportes gubernamentales, inventarios, compras y administración de redes. Otras

Industrias

 

Muchas otras industrias y actividades utilizan actualmente, o están comenzando a instalar,

Data Warehouse: entidades gubernamentales, especialmente para el control impositivo, empresas

de servicios públicos, de entretenimiento, editoriales, fabricantes de automóviles, empresas de

petróleo y gas, laboratorios farmacéuticos, droguerías, etc.

 

 

5. 6.      GLOSARIO DE TERMINOS   Aggregate

Es una tabla o estructura que contiene datos precalculados para un cubo. Soportan la rápida

y eficiente consulta de tablas multidimensionales.

 Base de datos (BD)

Conjunto de datos no redundantes, almacenados en un soporte informático, organizados de

forma independiente de su utilización y accesibles simultáneamente por distintos usuarios y

aplicaciones. La diferencia de una BD respecto a otro sistema de almacenamiento de datos es que

éstos se almacenan en la BD de forma que cumplen tres requisitos básicos: no redundancia,

independencia y concurrencia.

 

Cliente / servidor

Arquitectura de sistemas de información en la que los procesos de una aplicación se dividen

en componentes que se pueden ejecutar en máquinas diferentes. Modo de funcionamiento de una

aplicación en la que se diferencian dos tipos de procesos y su soporte se asigna a plataformas

diferentes.

 

Codificación

Transformación de un mensaje en forma codificada, es decir, especificación para la

asignación unívoca de los caracteres de un repertorio (alfabeto, juego de caracteres) a los de otro

repertorio. Conversión de un valor analógico en una señal digital según un código prefijado.

 

Cubo

Es el objeto central de los datos, contiene información en una estructura multidimensional.

Cada cubo es definido por un conjunto de dimensiones y medidas.

Data Mart

Es una estructura de datos que es optimizada para el acceso. Esta diseñada para facilitar el

acceso del usuario final. Soporta aplicaciones de análisis usadas por múltiples usuarios.

 

Detección de desviación

Normalmente, para la detección de desviación en bases de datos grandes se usa la

información explícita externa a los datos, así como las limitaciones de integridad o modelos

predefinidos. En un método lineal por contraste, se enfoca el problema desde el interior de los

datos, usando la redundancia implícita de los datos. Aquí se simula un mecanismo familiar a los

seres humanos: después de ver una serie de datos similares, un elemento que perturba la serie se

considera una excepción.

 

Diccionario de datos

Descripción lógica de los datos para el usuario. Reúne la información sobre los datos

almacenados en la Base de Datos (descripciones, significado, estructuras, consideraciones de

seguridad, edición y uso de las aplicaciones, etc.).

 

Directorio de datos

Es un subsistema del sistema de gestión de base de datos que describe dónde y cómo se

almacenan los datos en la Base de Datos (modo de acceso y características físicas de los

mismos).

 

Drill-down (Iniciar del nivel mas alto y bajar a detalle de nivel en nivel) 

Obtención de información más detallada sobre un conjunto de información en el cual se está

trabajando. Ejemplo: Si se está mirando el Activo, obtener todas las cuentas del activo.

 

Dimensión

Es una estructura o tributo de un cubo el cual es organizado por jerarquías de categorías o

niveles que describen datos en la fact table. Estas categorías describen un conjunto de miembros

sobre los cuales esta basado el análisis. Por ejemplo: una dimensión geográfica incluye niveles de

países, regiones, estados o provincias, y ciudades

 

Extranet

Constituye un servicio de comunicación orientado a un público centrado sobre el formato de

los sistemas Web, operando sobre la red Internet. Ejemplo: Una casa de ventas de productos

varios, implementa un sistema de Ofertas, Consulta a Catálogos, Bancos de Datos y Compras a

sus clientes preferenciales.

 

Fact Table

Contiene los indicadores clave identificados durante el proceso de análisis y que contienen

combinación de información de objetos y tiempo

 

Fact

Representa una fila en una fact table en el Data Warehouse. Contiene uno o más valores

numéricos que miden un evento.

 

Inconsistencia

El contenido de una base de datos es inconsistente si dos datos que deberían ser iguales no

lo son. Por ejemplo, un empleado aparece en una tabla como activo y en otra como jubilado.

Integridad

Condición de seguridad que garantiza que la información es modificada, incluyendo su

creación y borrado, sólo por el personal autorizado.

Internet

Término usado para referirse a la red más grande del mundo, que conecta miles de redes

con alcance mundial. Está creando una cultura que basándose en la simplicidad, investigación y

estandarización fundamentado en usos de la vida real, está cambiando la forma de ver y hacer

muchas de las tareas actuales. Mucha de la tecnología de punta en redes está proviniendo de la

comunidad Internet.

 

Intranet

Constituye un servicio de comunicación de los sistemas de información corporativos

orientados a su personal, sobre el formato de los sistemas Web, operando sobre la red Internet.

 

Mapeo

Conjunto de datos.

Lista de datos u objetos, tal como actualmente están almacenados en memoria o en disco.

Transferir un conjunto de objetos de un lugar a otro. Por ejemplo, los módulos de programas

en el disco son proyectados ("mapeados") en la memoria. Una imagen gráfica en memoria es

proyectada en la pantalla.

Relacionar un conjunto de objetos con otro. Por ejemplo, una estructura de base de datos

lógica se proyecta sobre la base de datos física.

 

Modelamiento predictivo (inteligencia artificial)

Las herramientas de modelamiento predictivo permiten realizar relaciones complejas o

modelos desde un archivo de datos. Una de las principales diferencias entre los modelos

estadísticos y los modelos de inteligencia artificial, es cómo miden su error. Los primeros miden el

error relativo tal como el modelo adapta los datos, mientras que los segundos, miden el error

relativo a los datos aún invisibles (error predictivo).

 

Los modelos estadísticos tienen dificultades al dar datos contradictorios o desordenados, es

decir, los datos deben estar limpios y deben existir las correlaciones consistentes. Viceversa, las

herramientas de inteligencia artificial buscan generalizar relaciones para proporcionar el resultado

más probable. El modelamiento abductivo (argumento en que la premisa mayor es evidente y la

menor probable, pero mas creíble que la conclusión) usa funciones polinómicas para describir las

relaciones al interior de los datos. Esta metodología facilita una variable de entrada para ser

ponderado más de una vez. Adicional, sólo se incluyen los términos que significativamente

contribuyen al rendimiento.

 

Los modelos predictivos pueden usarse para el soporte de decisión o presentando sub-

rutinas para desarrollar aplicaciones predictivas a clientes. Las capacidades de los modelos

predictivos pueden mejorarse si los archivos de datos se mejoran con tantas variables de entrada

como sea posible.

 

MetaData

Es el resultado de modelar los datos. Cuando se almacenan los datos en una herramienta o

en un repositorio.

 

Measure

Es una columna numérica cuantitativa en la fact table. Normalmente representa los valores a

analizar.

 

OLAP (Online Analytical Process)

Es un proceso de manejo de base de datos diseñado para la asistencia del soporte de

decisiones, utilizando herramientas que facilitan el análisis de estructuras dimensiónales de

negocios de información. Una típica base de datos OLAP provee, consolida, almacenan datos

consistentes, y datos históricos en formato de solo lectura.

 

OLTP (Online Transactional Process):

Es un sistema de manejo de base de datos que representa el estado de un negocio en

particular en un punto especifico en el tiempo. Un sistema OLTP tiene una gran cantidad de

usuarios concurrentes agregando y modificando datos.

 

Redundancia

Repetición de los mismos datos en varios lugares.

 

Repositorio

Base de datos central en herramientas de ayuda al desarrollo. El repositorio amplía el

concepto de diccionario de datos para incluir toda la información que se va generando a lo largo del

ciclo de vida del sistema, como por ejemplo: componentes de análisis y diseño (diagramas de flujo

de datos, diagramas entidad-relación, esquemas de bases de datos, diseños de pantallas, etc.),

estructuras de programas, algoritmos, etc. En algunas referencias se le denomina diccionario de

recursos de información.

 

Record

Calificación que se le da a un grupo de clientes / productos que mide la propensión a

compras, ventas, retiro, llegadas, etc.

 

Sistema de gestión de base de datos

Software que controla la organización, almacenamiento, recuperación, seguridad e

integridad de los datos en una base de datos. Acepta pedidos de datos desde un programa de

aplicación y le ordena al sistema operativo transferir los datos apropiados. Cuando se usa un

sistema de gestión de base de datos, SGDB, (en inglés DBMS), los sistemas de información

pueden ser cambiados más fácilmente a medida que cambien los requerimientos de la

organización. Nuevas categorías de datos pueden agregarse a la base de datos sin dañar el

sistema existente.

 

Sistema de información (SI)

Conjunto de elementos físicos, lógicos, de comunicación, datos y personal que,

interrelacionados, permiten el almacenamiento, transmisión y proceso de la información.

 

Software

Son las aplicaciones intangibles desarrolladas en un lenguaje de programación, para

resolver una necesidad especifica implementada a través de una computadora.

 

SQL (Structured Query Language)

Lenguaje de interrogación normalizado para bases de datos relacionales. El SQL es un

lenguaje de alto nivel, no procedural, normalizado, que permite la consulta y actualización de los

datos de BD relacionales. Se ha convertido en el estándar para acceder a BD relacionales. El SQL

facilita un lenguaje de definición de datos y un lenguaje de manipulación de datos. Además, incluye

una interfase que permite el acceso y manipulación de la BD a usuarios finales.

Terabyte (TB)

Unidad de medida que equivale a 1024 GB (gyga bytes)

 

Teradata

El Sistema de Gestión de Base de Datos Relacional (RDBMS) Teradata, es una base de

datos relacional paralela de soporte de decisiones muy poderosa para Data Warehouse. Teradata

también proporciona conectividad de cliente abierto a virtualmente todos los sistemas operativos.

 

 

CONCLUSIONES   

Las decisiones correctas son las que hacen la diferencia, y por lo tanto es necesario buscar

las herramientas adecuadas para lograr los objetivos deseados. La implementación de un Data

Warehouse, ayuda a tener una mejor visión de los sucesos y al mismo tiempo da un apoyo a la

toma de decisiones. En un mundo competitivo como el actual, ya no es posible quedarse sin

tecnología para apoyar la administración de los negocios. La información histórica juega entonces

un papel importante y definitivo en el rumbo de los negocios.

 

Comprender el proceso del negocio es una de las primordiales actividades que se deben

completar, para tener una visión macro de la compañía y poder así definir de mejor manera los

puntos clave que identifican las fortalezas y debilidades de una empresa.

 

Se recomienda que al realizar la implementación de un Data Warehouse, se realice un

estudio para definir la forma de administrar los recursos y se establezca una estrategia de

actualización de la carga de datos, dependiendo del tipo de negocio y la información que se desee

consultar. Además, es de vital importancia realizar la implementación con gente calificada y

especializada en la materia, ya que una mala definición de procedimientos podría traer como

resultado, una salida no esperada de información.

 

El éxito de Data Warehouse no está en su construcción, sino en usarlo para mejorar

procesos empresariales, operaciones y decisiones. Posesionar un Data Warehouse para que sea

usado efectivamente, requiere entender los impactos de implementación en los diferentes ámbitos

de la organización. Al construir un Data Warehouse, se requiere que las personas involucradas,

quienes usarán la información, participen directamente. A diferencia del desarrollo de aplicaciones,

donde los requerimientos de la empresa logran ser relativamente bien definidos producto de la

estabilidad de las reglas de negocio a través del tiempo. Construir un Data Warehouse depende de

la realidad de la empresa como de las condiciones que en ese momento existan, las cuales

determinan qué debe contener el Data Warehouse. La gente de negocios debe participar

activamente durante el desarrollo del Data Warehouse, desde una perspectiva de construcción y

creación.

 

En cuanto al acceso del Data Warehouse, este intenta proveer los datos que posibilitan a los

usuarios acceder su propia información cuando ellos la necesitan. Esta aproximación para entregar

información tiene varias implicancias:

 

       La gente de la empresa puede necesitar aprender nuevas destrezas.

       Los análisis extensos y las demoras de programación para obtener información

será eliminada. Como la información estará lista para ser accesada, las expectativas

probablemente aumentarán.

       Nuevas oportunidades pueden existir en la comunidad empresarial para los

especialistas de información.

       La gran cantidad de reportes en papel serán reducidas o eliminadas.

       La madurez del Data Warehouse dependerá del uso activo y retroalimentación de

sus usuarios.

 

El uso de aplicaciones de soporte para la toma de decisiones por parte de los usuarios de

aplicaciones, necesitarán menos experiencia para construir su propia información y desarrollar

nuevas destrezas. En conclusión, el valor de un Data Warehouse queda descrito en tres

dimensiones:

 

       Mejorar la Entrega de Información: Información completa, correcta, consistente,

oportuna y accesible. Información que la gente necesita, en el tiempo que la necesita

y en el formato que la necesita.

 

       Mejorar el Proceso de Toma de Decisiones: Con un mayor soporte de

información se obtienen decisiones más rápidas; así también, la gente de negocios

adquiere mayor confianza en sus propias decisiones y las del resto, y logra un mayor

entendimiento de los impactos de sus decisiones.

 

       Impacto Positivo sobre los Procesos Empresariales: cuando a la gente se le da

acceso a una mejor calidad de información, la empresa puede lograr por sí sola:

 

o o        Eliminar los retardos de los procesos empresariales que resultan de

información incorrecta, inconsistente y/o no existente.

o o        Integrar y optimizar procesos empresariales a través del uso compartido

e integrado de las fuentes de información.

o o        Eliminar la producción y el procesamiento de datos que no son usados

ni necesarios, producto de aplicaciones mal diseñados o no utilizados.

 

BIBLIOGRAFÍA 

  

Daniel Cohen, Enrique Asin Sistemas de Información para los negocios.Un enfoque de toma de decisiones. Enero, 2000.

Tercera Edición

McGrawHill / Interamericana Editores, S.A.

 

Barry Devlin Data Warehouse from architecture to implementation Agosto, 1997

Addison Wesley Longman, Inc.

 

Michael Corey, Michael Abbey

 

SQL Server 7, Data Warehousing

Osborne

McGrawHill

 

Microsoft Desinging and implementing a Data Warehousing using Microsoft SQL Server 7.0 Microsoft Training and Certification

  

  

BIBLIOGRAFÍA DE INTERNET                 www.datawarehousing.com

             www.dw-institute.com

             www.microsoft.com\olap

             www.inei.gob.pe

             www.oracle.com

             www.sybase.com

             www.desitersoft.com