Unidad1 pdf3 PDF

Información Estructurada II
1 © Asturias Corporación Universitaria

Índice
1 Componentes Asociados ................................................................................................................................ 3

2 Análisis de los Datos del DWH ................................................................................................................... 6
3 Explotación del DWH ....................................................................................................................................... 9
4 Plataformas para DWH ................................................................................................................................... 12
5 Consideraciones ................................................................................................................................................. 13
6 Conclusiones ........................................................................................................................................................ 14
7 Bibliografía Esencial ......................................................................................................................................... 14
8 Bibliografía Recomendada ........................................................................................................................... 14
02 ASTURIAS CORPORACIÓN UNIVERSITARIA®

Nota Técnica preparada por Asturias Corporación Universitaria. Su difusión, reproducción o uso total o
parcial para cualquier otro propósito queda prohibida. Todos los derechos reservados.
Objetivos
Los objetivos principales perseguidos en esta clase son:
• Estructura y componentes asociados en la arquitectura del DWH.
• Entender los conceptos de: data mart., ODS, OLAP y Data Mining.
• Profundizar en las consideraciones para un correcto desarrollo de un DWH.
1 Componentes Asociados
Área staging: ETL
Los datos de origen para el DWH pueden estar contenidos en varios sistemas
Los componentes asociados al DWH
diferentes. Para que el DWH sea cargado, un proceso debe ser desarrollado. Los datos
serían el área staging, procesos ETL y
de los sistemas origen deben ser:
capa de presentación (data marts,
reportes…)
• Extraídos de los sistemas de origen.
• Transformados para asegurar la compatibilidad con el modelo de datos del

DWH.
• Cargados en el DWH.
Esta secuencia de procesos se conoce como el proceso de ETL y sucede en el área de

ensayo o staging.
Los metadatos del negocio impulsan las reglas que los programas ETL necesitan
utilizar, ya que con esos metadatos técnicos se define el cómo realizar esas r eglas.
Metadatos
La definición de metadatos: literalmente, "datos sobre datos". Los metadatos incluyen

datos asociados, ya sea con un sistema de información o de un objeto de información

con fines de descripción, administración, requisitos legales, funcionalidad técnica, uso y

conservación.
Área staging: ETL y Staging
Por razones técnicas (disponibilidad de los sistemas fuente, planificación de extracción,

propósitos de auditoría, la complejidad de las transformaciones, etc.) puede que el área
de ensayo requiera un espacio de almacenamiento físico.
Este espacio de almacenamiento es por lo general un punto de destino para los datos
una vez que se han extraído por la ETL de los sistemas de origen. Este espacio de
almacenamiento Staging se encuentra antes de que cualquier transformación sea
llevada a cabo por el proceso de ETL.
Integración proceso ETL y área staging
Simplemente a modo de curiosidad, Ralph Kimball (uno de los autores más prestigiosos
de DWH) a menudo compara el área staging con la cocina de un restaurante. El cliente
nunca accede a ella y es el lugar dónde la información es preparada para ser servida a
los usuarios.
Es una especie de zona invisible sin acceso al usuario no viendo lo que hay ahí pero
absolutamente crítico para el sistema.
Capa de presentación: herramientas de reporte
Una vez que el DWH se ha aprovisionado con los datos integrados correctos, los
informes pueden ser creados para “recuperar" los datos y presentarlos de manera
efectiva a los usuarios de negocios.
La capa de presentación se encuentra en la parte superior del DWH y recopila datos

para las necesidades de información de los usuarios de negocios.

Herramientas de reporte
Capa de presentación: data marts
Como el DWH puede contener una gran cantidad de datos, se recomienda crear data
marts sobre temas específicos en la parte superior del DWH con el objetivo del acceso
a datos.
Estos data marts contendrán subconjuntos de temas específicos de los datos, que
contiene el DWH, por tanto, será más eficiente para la recuperación de datos. Estos
data marts no son un medio de reemplazo para el DWH y siempre deberían derivarse
del DWH.
Data marts

2 Análisis de los Datos del DWH
Las dos arquitecturas que podríamos encontrarnos sería disponer de data marts
El DWH es el componente central de la independientes (imagen izquierda) o data marts integrados (imagen derecho)
arquitectura de Business Intelligence.
Data marts
Data Marts independientes
La carga de datos desde los sistemas de origen a diversos data marts sin disponer de
un DWH que consolide la información y les sirva de origen da como resultado un
descontrol de los datos:
• Duplicados y datos redundantes
• Similares pero diferentes
• Independientemente de la arquitectura de BI, el DWH debe ser el componente

central de los datos consolidados.
• No tiene información compartida ni representación semántica de la misma con

problemas de integración frecuentes.
Suele ser planificado, diseñado e implementado por los diferentes departamentos,

grupos funcionales, o pequeñas divisiones

Data marts independientes
Data Marts integrados
Las características que implica esta visión de data marts integrados son:
• Cada data mart corresponde con un subconjunto lógico del almacén de datos.
• Están basados en los mismos datos.
• Uso de las definiciones comunes de datos, medidas y fórmulas de agregación

como el DWH.
Suele ser planificado, diseñado y ejecutado por una organización central de TI,
ejecutando una estrategia global de apoyo a la decisión
Data marts integrados
Un DWH podría consolidar Data Marts dispares
Algunas empresas informan desde data marts no consolidados (utilizando el modelo de

data mart independiente).
En este caso, sería posible el uso de estos data marts como sistemas de origen y crear
un DWH encima de ellos.

Data marts consolidados
En este enfoque podría crearse un datawarehouse mediante varios data marts que no
están linkados, de manera que los datos fueran consolidados. Este enfoque requiere
actividad de limpieza y calidad de los datos.
Destacar que es el enfoque opuesto a lo que sugieren las buenas prácticas, pero podría
ser aceptado dependiendo de los sistemas actuales de los clientes.
Diferencias potenciales entre un DWH y los data marts
En el siguiente cuadro se mencionan las diferencias potenciales que nos encontramos

entre un data warehouse y los datamarts.
Data Warehouse Data Mart
Usuario IT Grupo de negocio
Escala Empresarial Departamental
Coste Alto Contenido
Temporalidad Prolongada Acortado
Estrategia Empresarial Basada en objetivo
De arriba hacia De abajo hacia

Implementación
abajo arriba
Administración Centralizado Distribuído
Inversión Estratégico Táctico

3 Explotación del DWH
En la figura siguiente se ilustran los componentes que conforman un sistema completo

En función del tipo de información que de BI, éstos son:
almacenen y procesen podemos destacar
tres componentes asociados con la
explotación del DWH: ODS, OLAP y Data
Mining.
Marco de Arquitectura de sistema informacional
ODS: Operational Data Store
Un almacén operacional de datos, también llamado ODS (del inglés Operational Data
Store), es un contenedor de datos transaccionales, es decir, está diseñado para integrar
datos de múltiples fuentes con los que realizar operaciones adicionales en los propios
datos. A diferencia de un almacén de datos maestro, los datos no vuelven de nuevo a
los sistemas operacionales de origen, sino que se preparan para la realización de otras
operaciones o para ser incorporados a un almacén de datos (o data warehouse) para
ser explotados en la realización de informes. Por tanto, se puede decir que un sistema
ODS estará ubicado entre uno o varios sistemas OLTP (origen) y un sistema OLAP
(destino).
Dado que los datos se originan a partir de múltiples fuentes, la integración a menudo
implica limpiar dichos datos, resolver redundancias y comprobar la integridad de los
mismos según las reglas del negocio. Un ODS está generalmente diseñado para
contener datos atómicos (indivisibles). Al contrario que los almacenes de datos la
actualización de los datos se realiza con una ventana temporal muy pequeña (a veces
en tiempo real), y contiene un histórico limitado de los mismos (volátil), por lo que se
pueden considerar un área de memoria temporal (los almacenes de datos constituyen
un histórico de datos completo y persistente).

El propósito general de un ODS es integrar los datos de los sistemas de origen dispares
en una sola estructura, utilizando las tecnologías de integración de datos como la
virtualización de datos, la federación de datos, o de extracción, transformación y carga.
Esto permitirá el acceso operacional a los datos, es decir, permitirá la realización de
informes bajo demanda, la gestión del maestro de datos o de datos de referencia.
Un ODS no sustituye a un almacén de datos, sino que puede convertirse en una de sus
fuentes.
Operational Data Store
OLAP: On-Line Analytical Processing
OLAP es el acrónimo en inglés de procesamiento analítico en línea (On -Line Analytical

Processing). Es una solución utilizada en el campo del Business Intelligence cuyo
objetivo es agilizar la consulta de grandes cantidades de datos. Para ello utiliza
estructuras multidimensionales (o Cubos OLAP) que contienen datos resumidos de
grandes Bases de datos o Sistemas Transaccionales (OLTP). Se usa en informes de
negocios de ventas, marketing, informes de dirección, minería de datos y áreas
similares.
Cubos OLAP
La razón de usar OLAP para las consultas es la rapidez de respuesta. Una base de datos
relacional almacena entidades en tablas discretas si han sido normalizadas. Esta

estructura es buena en un sistema OLTP pero para las complejas consultas multitabla
es relativamente lenta. Un modelo mejor para búsquedas (aunque peor desde el punto
de vista operativo) es una base de datos multidimensional.
La principal característica que potencia a OLAP, es que es lo más rápido a la hora de

ejecutar sentencias SQL de tipo SELECT, en contraposición con OLTP que es la mejor
opción para operaciones de tipo INSERT, UPDATE Y DELETE.
Entorno OLAP
Data Mining (minería de datos)
Minería de datos es el proceso de descubrir significados, correlaciones ocultas

buscando a través de grandes cantidades de datos almacenados en los repositorios,
utilizando tecnologías de reconocimiento de patrones, así como técnicas estadísticas y
matemáticas.
La minería de datos generalmente se dirige a datos atómicos (por ejemplo, los datos de
las cestas de la compra), utilizando una aplicación cliente en el servidor de Data Mining
que extrae un subconjunto de datos del DWH.
Una vez revelada, esta información puede ser analizada y explotada, permitiendo así
producir un mayor valor a partir de los datos (es decir, agrupamiento, clasificación,
predicción, previsión, macheo).

Data mining
El ejemplo típico es sobre los productos que con frecuencia están presentes juntos en
la misma cesta de la compra (es decir, la fresa y la crema, cerveza y frutos secos, etc.)
En la minería de datos, la función principal sobre el DWH es extraer un conjunto de

observaciones sobre las que se desea extraer cierta información utilizando el servidor
de minería de datos. Una vez que usted produce los resultados de minería de datos se
deben mostrar a los usuarios de negocios, pero también pueden alimentar de nuevo a
los sistemas heredados y DWH con esta información obtenida.
4 Plataformas para DWH
Algunos de los sistemas gestores bases de datos y plataformas más comúnmente

Algunas de las plataformas más conocidas utilizados en entornos de data warehousing se corresponderían con los siguientes
para DWH son IBM InfoSphere, SAP Business
proveedores.
Warehouse, Teradata Warehouse, Oracle, etc.
IBM → InfoSphere Warehouse es la nueva oferta que IBM ha introducido para facilitar a
las empresas una mejor gestión de sus crecientes cantidades de datos, aunando en una
misma solución capacidades de archivo y data warehousing. La base de datos de IBM
se llama Netezza.
Teradata → Warehouse es una solución completa y potente que integra la tecnología

de base de datos paralela Teradata junto con plataformas hardware que crecen con las
necesidades de la empresa.
Oracle → El sistema gestor de base de datos se llama Oracle. Además esta compañía
ofrece una plataforma de almacenamiento de datos junto con una seria de aplicaciones.
SAP → tiene la aplicación Business Warehouse (BW). Es diferente a cualquier otra

aplicación de almacenamiento de datos en el mercado. SAP BW se ejecuta en las bases
de datos RDBMS tradicionales - o en la base de datos de SAP HANA en memoria para
un rendimiento extraordinariamente rápido. Es capaz de integrar aplicaciones SAP y no
SAP en un único entorno - para obtener una única versión de la verdad.
Microsoft → Microsoft SQL Server es un sistema gestor de bases de datos del modelo
relacional, desarrollado por la empresa Microsoft.

5 Consideraciones
¿Cuál es la implicación de coste?
Algunos de los costes asociados a la creación de un DWH serían:

Los proyectos de DWH tienen una alta
• El equipo de desarrollo durante el ciclo de vida del proyecto
implicación de costes
• El software involucrado: RDBMS, herramientas ETL, herramienta de informe, etc.
• Los costes de hardware: discos, redes, servidores de base de datos y ETL, PCs
de escritorio
• Los costes de personal interno: la gente senior del negocio, expertos en sistemas
origen
• La formación al usuario
• La formación de TI
• Los costes en la continuación del sistema: mantenimiento, cambios en los

sistemas de origen, desarrollos futuros, etc.
• El coste total de propiedad (TCO)
Diez maneras de fomentar un desastre completo
A modo de resumen y buenas prácticas, a continuación, se detallan las diez cosas

típicas que fomentarán a que el proyecto sea un completo desastre:
• Adoptar la visión y la misión de cada departamento dentro de la organización.
• Contar con un apoyo débil o sin él de la gestión.
• No involucrar a la comunidad de usuarios: "créalo y ellos vendrán ..."
• No perfilar los datos.
• Dejar pruebas de rendimiento hasta después de la aplicación.
• Utilizar la tecnología inapropiada.
• Tener una sola estrategia de publicación.
• No preocuparse por la actualización de los datos.
• Tratar de hacerlo todo a la vez.
• Ejecutarlo y abandonar el proyecto.

6 Conclusiones
Para finalizar con éxito el desarrollo de un DWH se debe “pensar en grande empezando
en pequeño” con la siguiente implicación:
• Tener la visión, y ser paciente en la implementación de la visión.
• Asegurar que el modelo de datos abarca todas las dimensiones clave del
negocio centrándose en el avance de la consecución de retos particulares
evitando así la “parálisis de análisis”.
• Mostrar capacidad para ofrecer un valor rápido y para comunicar y adherir para
iterar técnicas de diseño.
7 Bibliografía Esencial
La siguiente bibliografía debería ser leída con atención con el fin de que se afiancen los
conocimientos teóricos expuestos el tema.
• MundoDB, web especializada en bases de datos
http://mundodb.es/diseno-data-warehouse-hechos-y-dimensiones-modelo-
estrella-vs-copo-de-nieve
• Dataprix, organización especializada en software empresarial
http://www.dataprix.com/componentes-tener-en-cuenta-la-hora-de-construir-
un-data-warehouse
• Wikipedia, enciclopedia digital.
Enlace:
https://es.wikipedia.org/wiki/Sistema_de_procesamiento_de_transacciones
8 Bibliografía Recomendada
En las siguientes comunidades se puede ampliar profundamente sobre los temas vistos
en el tema.
• MundoDB, web especializada en bases de datos

http://mundodb.es/category/business_intelligence
• Monografías, portal con trabajos y documentación.
Enlace:https://www.monografias.com/trabajos17/data-warehouse/data-
warehouse.shtml


Unidad1 pdf3 PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Unidad1 pdf3 PDF

Cargado por

Copyright:

Formatos disponibles

Información Estructurada II

1 © Asturias Corporación Universitaria

1 Componentes Asociados ................................................................................................................................ 3

02 ASTURIAS CORPORACIÓN UNIVERSITARIA®

• Estructura y componentes asociados en la arquitectura del DWH.

• Profundizar en las consideraciones para un correcto desarrollo de un DWH.

Área staging: ETL

• Transformados para asegurar la compatibilidad con el modelo de datos del

Esta secuencia de procesos se conoce como el proceso de ETL y sucede en el área de

La definición de metadatos: literalmente, "datos sobre datos". Los metadatos incluyen

03 ASTURIAS CORPORACIÓN UNIVERSITARIA®

con fines de descripción, administración, requisitos legales, funcionalidad técnica, uso y

Área staging: ETL y Staging

Por razones técnicas (disponibilidad de los sistemas fuente, planificación de extracción,

Integración proceso ETL y área staging

Capa de presentación: herramientas de reporte

La capa de presentación se encuentra en la parte superior del DWH y recopila datos

04 ASTURIAS CORPORACIÓN UNIVERSITARIA®

Capa de presentación: data marts

05 ASTURIAS CORPORACIÓN UNIVERSITARIA®

2 Análisis de los Datos del DWH

Data Marts independientes

• Duplicados y datos redundantes

• Similares pero diferentes

• Independientemente de la arquitectura de BI, el DWH debe ser el componente

• No tiene información compartida ni representación semántica de la misma con

Suele ser planificado, diseñado e implementado por los diferentes departamentos,

06 ASTURIAS CORPORACIÓN UNIVERSITARIA®

Data marts independientes

Data Marts integrados

• Están basados en los mismos datos.

• Uso de las definiciones comunes de datos, medidas y fórmulas de agregación

Data marts integrados

Un DWH podría consolidar Data Marts dispares

Algunas empresas informan desde data marts no consolidados (utilizando el modelo de

07 ASTURIAS CORPORACIÓN UNIVERSITARIA®

Data marts consolidados

Diferencias potenciales entre un DWH y los data marts

En el siguiente cuadro se mencionan las diferencias potenciales que nos encontramos

Data Warehouse Data Mart

Usuario IT Grupo de negocio

Escala Empresarial Departamental

Coste Alto Contenido

Temporalidad Prolongada Acortado

Estrategia Empresarial Basada en objetivo

De arriba hacia De abajo hacia

Administración Centralizado Distribuído

Inversión Estratégico Táctico

08 ASTURIAS CORPORACIÓN UNIVERSITARIA®

3 Explotación del DWH

En la figura siguiente se ilustran los componentes que conforman un sistema completo

Marco de Arquitectura de sistema informacional

ODS: Operational Data Store

09 ASTURIAS CORPORACIÓN UNIVERSITARIA®

Operational Data Store

OLAP: On-Line Analytical Processing

OLAP es el acrónimo en inglés de procesamiento analítico en línea (On -Line Analytical

010 ASTURIAS CORPORACIÓN UNIVERSITARIA®

La principal característica que potencia a OLAP, es que es lo más rápido a la hora de

Data Mining (minería de datos)

Minería de datos es el proceso de descubrir significados, correlaciones ocultas

011 ASTURIAS CORPORACIÓN UNIVERSITARIA®

En la minería de datos, la función principal sobre el DWH es extraer un conjunto de