Monografias.com > Administración y Finanzas
Descargar Imprimir Comentar Ver trabajos relacionados

El Datawarehouse: nueva perspectiva de consulta para las empresas




Enviado por dialys



    1. Resumen
    2. Desarrollo
    3. Conclusiones
    4. Bibliografía
    5. Anexo

    RESUMEN

    Los principales objetivos de
    este artículo se orientan hacia la construcción de un Datawarehouse que
    está dirigido fundamentalmente a responder de manera
    rápida a las solicitudes de análisis de los directivos de las empresas. Un
    lugar importante en la construcción del Datawarehouse lo
    ocupa el área de transformación de los datos, la cual
    varía en su complejidad en dependencia de los
    requerimientos del problema.

    Palabras claves: datawarehouse, back room,
    área de transformación de datos, modelo
    dimensional

    Introducción

    Para aquellos que desarrollan y mantienen los sistemas de datos
    haciéndolos disponibles para los directivos de las
    empresas, el término DataWareHouse o también
    conocido como Almacén de Datos, ofrece la
    solución como ubicación central para que todos
    puedan acceder a la información con los reportes necesarios,
    dando respuesta a necesidades de diferentes tipos de
    usuarios.

    El Datawarehouse (en lo adelante nos referiremos como
    DWH) surgió con el objetivo de
    hacer consultable la información que se tiene de una empresa tanto
    de meses como de años anteriores.

    El DWH organiza y orienta los datos desde la perspectiva
    del usuario final, mientras que los sistemas operacionales
    organizan sus datos desde la perspectiva de la aplicación,
    para lograr eficiencia en el
    acceso a datos.

     Los principales objetivos de un Datawarehouse
    son:

    • Comprender las necesidades de los usuarios por
      áreas dentro del negocio.
    • Determinar qué decisiones se pueden tomar con
      la ayuda del DWH
    • Seleccionar un subconjunto del sistema de
      fuentes de
      datos que sea el más efectivo y procesable para
      presentar el DWH.
    • Asegurar que los datos sean precisos , correctos y
      confiables y que mantengan la consistencia .
    • Monitorear continuamente la precisión y
      exactitud de los datos y el contenido de los reportes
      generados.
    • Publicar los datos.

    Desarrollo

    ¿Por qué se justifica construir un
    Datawarehouse?

    Generalmente, los sistemas transaccionales o OLTP usan
    estructuras
    normalizadas, en las cuales se optimizan las inserciones y
    actualizaciones de artículos e incluso algunas
    selecciones, pero es menos probable que el sistema se organice de
    forma tal que produzca reportes eficientes para datos resumidos
    con cierta jerarquía. Y es aquí donde
    debería usarse el DWH, que usa los datos relevantes de
    fuentes existentes y los combina en una estructura que
    ha sido optimizada para las selecciones.

    Esta es la razón por la cual se construye un
    datawarehouse para solucionar la problemática de tener un
    sistema fuente transaccional corriendo sobre un servidor Novell. Esta
    información se necesita que esté consultable para
    los clientes de
    la empresa de
    forma remota y sin embargo, por problemas de
    seguridad no
    puede estar directamente disponible desde el mismo sistema
    fuente. El datawarehouse ha sido la solución propuesta
    para que la información sea utilizada por una
    aplicación cliente de acceso
    remoto. De esta forma se aprovecha la forma en que se organizan
    los datos en el almacén en
    el modelo dimensional y se brinda a la Gerencia un
    grupo de
    informaciones organizadas en cubos multidimensionales que les
    permite profundizar en el análisis de la
    información y ver su variación en el tiempo.

    Un DWH debe tener cuatro características que son
    primarias . Es una colección de datos orientada a un
    tema , integrada
    , variable en el tiempo y no
    volátil
    que sea útil para la toma de
    decisiones.

    Es orientada a un tema porque tiene en cuenta los
    procesos de
    negocio de la empresa que se
    deseen priorizar. Es integrado porque agrupa a todos los
    sistemas operacionales en un sistema de
    información con formatos y códigos
    consistentes. Es variante en el tiempo porque los datos se
    organizan y almacenan en jerarquías en el tiempo, lo que
    permiten análisis comparativos de estados actuales y de
    períodos anteriores. Es no volátil porque se
    usa principalmente para operaciones de
    recuperación de información y no para
    actualizaciones.

    Los DWH están en la categoría de los
    sistemas para el soporte de decisiones (DSS) que tienen como
    objetivos medir y controlar el desarrollo de
    las variables
    importantes del negocio, buscando identificar, proyectar y
    predecir tendencias a partir de los datos acumulados.

    Los datos que se manejan en el DWH son informacionales ,
    esto significa que son datos resumidos y periódicos a
    diferencia de los datos operacionales.

    Cuáles pudieran ser consultas típicas en
    este sistema para la toma de decisiones de la
    empresa?.

    • ¿Cuál ha sido el total de ingresos de los
      clientes por meses y años?
    • ¿Cuáles han sido los pagos realizados
      por los clientes y por qué conceptos?
    • ¿Cuáles han sido las principales
      cadenas hoteleras que aportan a sus Casas Matrices?

    Con la creación de un DWH, se persigue un sistema
    de fácil comprensión y de rápida
    ejecución que significa datos de alta calidad, con un
    diseño
    que permita los cambios y además, una salvaguarda segura
    para proteger la información.

    Partes del DWH

    El DWH necesita de tres áreas bien diferentes
    entre sí pero que se integran para lograr un buen
    funcionamiento:

    • Los sistemas origen o fuentes legados
      .
    • El área de transformación de los datos
      (en lo adelante nos referiremos como ATD)
    • El Servidor de presentación del
      DWH

    (Ver Anexo1)

    Las fuentes legados son
    los sistemas de procesamiento que capturan las transacciones del
    negocio. Deben ser sistemas confiables y consistentes , aunque
    entre ellos hay marcadas diferencias en los formatos y las
    estructuras de los datos. Quedan fuera del DWH por lo que no
    tenemos el control sobre el
    contenido de sus datos.

    El área de transformación de los
    datos
    (ATD) consta tanto del área de almacenamiento
    como del conjunto de procesos que se usan frecuentemente para la
    extracción, transformación y carga de los datos .
    Es generalmente la parte más compleja de esta arquitectura. Es
    todo lo que se presenta entre la fuente externa y el área
    de presentación de los datos.

    El servidor de presentación es la fuente
    consultable de datos de la empresa. Es donde se organizan los
    datos del DWH , se almacenan y están disponibles para
    hacer consultas, reportes y acceder mediante
    aplicaciones.

    Concretamente, el área de transformación
    de datos puede estar constituida por un grupo de servicios de
    transformación de datos que pueden ser implementados para
    mantener actualizada la información del almacén
    haciendo algunas transformaciones a los datos.

    El DWH se soporta sobre el modelo dimensional a
    diferencia de los sistemas de bases de datos
    que están basados en el modelo
    Entidad-Relación
    . Este modelo contiene la misma
    información que el modelo E/R pero empaqueta los datos en
    un formato simétrico cuyo objetivo es ganar una mayor
    comprensión del usuario y garantizar la ejecución
    rápida y eficiente de las consultas. A diferencia del
    modelo E/R, el modelo dimensional no necesita anticipar las
    consultas que se van a realizar y es muy elástico a los
    cambios que se produzcan en los patrones de los
    usuarios.

    El modelo dimensional divide el mundo de los datos en
    dos grandes tipos: las medidas y las descripciones del entorno de
    estas medidas. Las medidas, que generalmente son
    numéricas, se almacenan en las tablas de hechos y
    las descripciones de los entornos que son textuales se almacenan
    en las tablas de dimensiones. Las tablas de hechos son las
    tablas primarias en el modelo dimensional y contiene los valores
    del negocio. Los hechos más comunes son valores
    numéricos . Cada tabla representa una interrelación
    muchos – muchos y contiene dos o más llaves
    extranjeras que acoplan con sus respectivas tablas de
    dimensiones.

    Las tablas de dimensiones son las compañeras de
    las tablas de hechos. Cada dimensión se define por su
    llave primaria que sirve para mantener la integridad referencial
    en la tabla de hechos a la que se acopla. Los atributos de estas
    tablas sirven de base a las solicitudes que se hacen al
    DWH.

    Las tablas de dimensiones contienen información
    jerárquica que permitirán la realización de
    las agregaciones o las profundizaciones.

    En el Anexo # 2 se muestra un modelo
    dimensional propuesto para una institución financiera
    basado en un esquema de estrella.

    Para conformar la tabla de hechos se tuvo en cuenta el
    hecho principal del problema que es la operación
    financiera de un cliente, la cual se mide por el importe de la
    operación. En la operación intervienen
    además del código
    del cliente que hizo la operación, el desglose de la
    cuenta, la moneda en que se hizo, el concepto y la
    fecha y sobre estas descripciones se conformaron las dimensiones
    que se actualizan de los clasificadores del sistema
    fuente.

    Para acceder al servidor de presentación se
    implementan las herramientas de acceso de datos del usuario
    final
    . Estas herramientas
    constituyen el cliente del DWH que mantiene una interacción con el servidor enviando a
    éste solicitudes SQL y devuelve
    los resultados ya sea en pantalla , o en un reporte o un
    gráfico o alguna otra forma superior de análisis
    para el usuario. Estas herramientas pueden ser tan simples como
    las consultas ad-hoc o tan complejas como la
    minería de datos . Las consultas ad-hoc se
    establecen cuando el usuario forma sus propias consultas
    manipulando directamente las tablas relacionales y sus conexiones
    . Se usa solamente por un 10% de todos los usuarios finales del
    DWH ya que el resto prefiere usar las aplicaciones.

    Para dar uso al almacén y acceder de forma remota
    a esa información, se implementa una aplicación
    cliente basada en tecnología web aprovechando
    la ventaja de que esta aplicación se puede invocar desde
    cualquier máquina haciendo conexión remota
    independientemente del sistema operativo
    que tenga implantado. Las consultas que hace la aplicación
    al servidor de los datos se realizan invocando procedimientos
    almacenados que están en el servidor y que agilizan
    notablemente dichas consultas.

    Otra de las herramientas que se utilizan en el Servidor
    de Presentación es el Procesamiento Analítico en
    Línea (OLAP)
    , el cual permite crear vistas
    multidimensionales de los datos sobre las bases de datos
    tradicionales.

    El procesamiento analítico en línea se
    puede ver como la síntesis,
    análisis y consolidación de grandes
    volúmenes de datos empresariales en la perspectiva de
    múltiples dimensiones tales como el tiempo, los clientes,
    las cadenas, las operaciones
    financieras, etc. Este análisis en línea de los
    datos puede utilizar fórmulas matemáticas y análisis
    estadísticos para consolidar y resumir los
    datos.

    Los requerimientos del negocio son los que dirigen la
    arquitectura de diseño de un DW por lo que se debe tener
    bien claro todos los asuntos del negocio, las estrategias, los
    procesos, la disponibilidad y las expectativas de
    ejecución del negocio.

    La arquitectura del DWH se convierte en el esquema de
    producción . Esta no es un plan de proyectos o una
    lista de tareas. Es el "qué" se debe hacer y no
    cómo y por qué. Desarrollar una arquitectura es
    difícil, pero posible y decisiva para el éxito
    del DWH. Está dirigida por el negocio, es decir, los
    requerimientos del negocio traen implicaciones técnicas
    sobre la arquitectura. Por ejemplo: las actualizaciones nocturnas
    conllevan a adecuar el procesamiento en el ATD; si se quiere
    tener una disponibilidad a nivel mundial se requiere de servidores
    distribuidos o paralelos; etc.

    Back Room o Area de transformación de
    datos

    El área técnica de una arquitectura de DWH
    se divide en dos subconjuntos: el back room y front room . El
    back room es la parte responsable de preparar los datos y el
    front room de entregarlos a los usuarios.

    El back room es el área donde tienen lugar
    los procesos de transformación de los datos y coincide con
    el área de transformación de datos.

    El principal interés de
    los administradores de las Base de datos
    y de sistema en esta parte es resolver el problema de tomar los
    datos correctos del punto A al punto B y hacer las
    transformaciones apropiadas en un tiempo adecuado.

    Los almacenes de
    datos, en su mayoría, se encuentran en el back room
    del DWH en pequeños y medianos tamaños. Lo que
    usted necesita para su diseño depende en gran medida de
    los requerimientos de su problema y la complejidad de los
    procesos de extracción y transformación que va a
    desarrollar.

    A modo de resumen, podemos plantear que para crear la
    arquitectura del back room es decisivo comprender la naturaleza de
    las fuentes de datos y qué formas van a tomar.

    El área de transformación de datos es el
    banco de
    trabajo del
    DWH. Su propósito es dejar el dato listo para el servidor
    de presentación, ya sea un DBMS relacional o un motor
    OLAP.

    Una característica distintiva de esta área
    es que aquí se crean las tablas de dimensiones, las cuales
    se replican en todos los mercados de datos
    que lo requieran.

    Una vez que los datos se extraen del sistema fuente, se
    le aplican una serie de transformaciones para convertirlos en
    algo presentable a los usuarios y de valor para el
    negocio.

    Los procesos en el ATD están guiados en esencia
    por metadatos que incluyen las reglas del negocio. Los metadatos
    se usan con herramientas administrativas para guiar las
    extracciones de los datos, transformaciones, archivo y carga
    en los mercados de datos y en el esquema del DWH.

    Los metadatos se definen como datos acerca de los datos.
    Son como el mapa de carretera hacia los datos.

    Se plantea que el proceso de
    creación y manejo de los datos en el DWH está
    formado por varios pasos de los cuales en su mayoría
    involucran metadatos y el DWH en su totalidad depende de
    ellos.

    El catálogo de metadatos juega un papel decisivo
    en la arquitectura del DWH , ya que suministra los
    parámetros y la información que permite que la
    aplicación realice sus tareas; contiene un conjunto de
    información de control del DWH, su contenido, sus fuentes
    de origen y sus procesos.

    Hasta este punto, el catálogo de datos es
    sólo un concepto lógico y cualquier cambio en
    él se reflejará en toda la arquitectura y
    estará disponible para todos los servicios a la
    vez.

    En la mayoría de los casos, no es muy
    práctico traer toda la información a un solo lugar.
    Los metadatos existen en varias herramientas, programas y
    utilitarios que hacen que el DWH funcione.

    Kimball [4] presentó un grupo de transformaciones
    que pudieran ser incluidas en el DWH que vamos a
    crear:

    • Integración: implica generar llaves
      sustitutas para las dimensiones, mapear las llaves de un
      sistema con otro y mapear los códigos con las
      descripciones completas.
    • Mantenimiento lento en los cambios en las
      dimensiones
      : identificar los valores que han cambiado y
      crear las llaves sustitutas asociadas es un proceso que
      encierra trucos en lugar de hechos
      matemáticos.
    • Chequeo de integridad referencial : la
      integridad referencial significa que los datos en una tabla
      estén en correspondencia con sus iguales en la otra
      tabla. La integridad referencial se pudiera manejar a nivel de
      base de datos en vez de cómo parte del proceso de
      transformaciones pero reduciría su
      flexibilidad.
    • Denormalización : convertir una
      jerarquía de tablas separadas en una dimensión es
      un proceso estándar de transformación del DWH.
      Este proceso consiste en abandonar las reglas de normalización y permitir los datos
      repetitivos con el objetivo de dar mayor comprensión y
      fácil ejecución a las consultas.
    • Limpieza y depuración : limpiar los
      datos. Este es un proceso complejo especialmente con aquellos
      DWH que tienen que ver con entidades externas como clientes,
      compañías, doctores y pacientes, pero ya existen
      proveedores
      que ofrecen herramientas y servicios específicos para
      ello.
    • Conversión del tipo de datos : Hacer
      transformaciones a bajo nivel que conviertan un tipo de datos o
      formato en otro. Por ejemplo: convertir las representaciones
      numéricas, de carácter de una base de datos a
      otra.
    • Asignaciones y cálculos : Hacer
      transformaciones se aplican a las reglas del negocio que se
      identifican durante el proceso. Un ejemplo pudiera ser llevar a
      mayúsculas el campo nombre del usuario para hacer
      más legibles los reportes.
    • Agregación : se maneja en el proceso de
      carga, en dependencia de los recursos que
      estén disponibles en cada etapa.
    • Auditoría del contenido de los datos :
      Procesar sumas de chequeo, contadores de filas y chequearlos
      contra las fuentes para alertar cuando no se correspondan. Es
      imposible chequear todo, pero sí algunas pruebas
      sólidas ahorrarían gasto de tiempo y
      errores.
    • Valores nulos : Identificar cuales son los
      valores sustitutos para los nulos y desarrollar reglas para
      manejarlos en las bases de datos.

    Integridad referencial

    El DWH como sistema de base de datos, debe mantener la
    integridad referencial y para implementarla, se procesan primero
    las dimensiones antes que los hechos. Se crean llaves sustitutas
    en el fichero de las dimensiones antes de cargarlo en el mercado de datos.
    La identificación de estas llaves consiste en una
    búsqueda en el fichero de forma secuencial.

    Cada llave del DWH debe ser una llave sustituta pues
    debe ser flexible a los cambios en las descripciones y a las
    condiciones anormales que se produzcan en la fuente de datos, es
    por ello que se plantea que las llaves productoras pueden ser
    reusadas y reformateadas.

    La correspondencia entre las llaves productoras y los
    valores de las dimensiones se lleva a cabo con una simple
    revisión a través de los datos fuentes y los datos
    de la tabla de dimensión.

    Seguridad en el back room

    La seguridad no es tan importante en el back room como
    en el front room. Esto se debe a que el back room es una
    actividad que tiene que ver con el desarrollo de aplicaciones y
    son suficientes las reglas de seguridad estándar de los
    sistemas. Sin embargo, debemos prestar atención al proceso de movimiento de
    los datos ya que si éstos se van a mover a través
    de la red aunque sea
    interna, siempre se paga caro y se corren riesgos. Es
    importante asegurarse de que se está utilizando un
    utilitario de transferencia de ficheros que use un protocolo
    seguro.

    Otro aspecto a tener en cuenta en esta área es
    determinar quién va a tener accesos de administración al servidor de DWH y al
    software. Con
    respecto a este tema, Kimball [3] plantea que se ven situaciones
    donde no hay uno en el equipo que tenga privilegios de administración y otros casos, donde todo el
    mundo tiene acceso a todo. Ninguna de las dos es la correcta,
    porque en el primer caso si sucede una situación anormal
    en la máquina donde está el DWH, se necesitan
    privilegios de administración para resetearla y reiniciar
    todo de nuevo. Con respecto al segundo caso, lo general es no
    darle acceso a todo el mundo pues el servidor de DWH debe estar
    estrictamente controlado y solo se otorgan privilegios de
    administración a algunos miembros del equipo de
    DWH.

    Conclusiones

    El concepto de DWH está teniendo una gran
    aplicación en la actualidad para el desarrollo de las
    empresas, como almacén de datos. Sus objetivos incluyen la
    reducción de los costes de almacenamiento y una mayor
    velocidad de
    respuesta frente a las consultas de los usuarios. Estos pueden
    ahora analizar y realizar preguntas sobre años, más
    que sobre meses de información.

    Para diseñar una buena arquitectura de DWH es
    necesario como primer paso conocer bien los requerimientos del
    negocio y hacer un estudio profundo de las fuentes externas que
    nos van a suministrar los datos. Además, hacer un buen
    diseño del área de transformación de datos,
    cuáles son las transformaciones que se van a realizar y
    cómo se va a implementar el modelo dimensional con sus
    tablas de hechos y de dimensiones es el segundo paso a
    seguir.

    Resumiendo los beneficios de la arquitectura del DWH
    :

    • Provee un esquema de organización – cuáles son
      los componentes que la forman, cómo ellos se
      interrelacionan, quién es el dueño de cada parte
      y cuáles son las prioridades.
    • Mejora la flexibilidad – permite que
      rápidamente se añadan nuevas fuentes de
      datos.
    • Desarrollo rápido y reuso – los
      desarrolladores de DWH son más capaces de comprender el
      proceso de DWH , los contenidos de las bases de datos y las
      reglas del negocio más rápidamente.
    • Herramientas de comunicaciones – define y comunica la
      dirección y el alcance de las
      expectativas , identifica los roles y responsabilidades y
      comunica los requerimientos al proveedor.

    En general, podemos plantear que el Datawarehouse
    representa una oportunidad para estrechar las relaciones de las
    empresas con los clientes.

    • Bibliografía

    [1] Hadley L., "Developing a Data Warehouse
    Architecture", extraido el 28 de febrero de 2003 de
    http://www.users.qwest.net/~lauramh/resume
    .

    [2] Kimball R., " Build your DataWarehouse one piece at
    a time" , Datawarehouse Designer, Octubre 2002. Extraido el 4 de
    marzo del 2003 de http://www.iemagazine.com/021030

    [3] Kimball R., "Is Data Staging Relational?" DBMS,
    April 1998 . Extraido el 26 de febrero de 2003 de http://www.dbmsmag.com

    [4] Kimball R., Laura Reeves, Margy Ross & Warren
    Thornthwaite, The Data Warehouse Life Cycle Toolkit, New York :
    John Wiley & Sons, 1998.

    Anexo # 1

    Para ver el gráfico seleccione la
    opción "Descargar" del menú superior

    ANEXO # 2 ALMACEN DE DATOS – ESQUEMA DE
    ESTRELLA

    MODELO DIMENSIONAL

    Para ver el gráfico seleccione la
    opción "Descargar" del menú superior

     

    Datos de la autora:

    Dialys Nerely Pérez de Armas

    Estudios realizados: Licenciada en Cibernética
    Matemática

    Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior.

    Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.

    Categorias
    Newsletter