Errores comúnes en la implantación de un DW

10) Aceptar de que aquellos quienes son responsables de los sistemas que interactuarán con el Data Warehouse y por este motivo no involucrarlos totalmente en el proyecto.

9)Una vez se ha desplegado el datawarehouse, sólo se realizarán comunicaciones a los usuarios finales si el presupuesto aún alcanza

8)Llevar al equipo de datawarehouse a unas oficinas separadas de los usuarios de negocio y limitar su interacción con ellos a través de un número de teléfono de soporte

7)Entrenar a los usuarios en todas las funcionalidades de la herramienta de acceso a datos con información de prueba (la información productiva aún no está lista) y declarar que ha sido un éxito pues el datawarehouse ya está desplegado

6)Asumir que los usuarios de negocio comenzarán a desarrollar sus propias aplicaciones analíticas en cuanto el datawarehouse esté en marcha

5)Antes de comenzar la implantación del datawarehouse, realizar un sesudo análisis de todas las áreas clave de la empresa al máximo detalle. Eso del diseño iterativo es sólo una excusa para no hacerlo todo bien a la primera

4)No involucres  a los directivos de la empresa hasta que tengas el datawarehouse implementado y puedas enseñar algo tangible. Tu astuto plan será convencerlos cuando vean las maravillas que un datawarehouse ya montado puede proporcionarles.

3)Anima a los usuarios de negocio a que estén constantemente dando feedback sobre el desarrollo e informando de nuevas métricas y fuentes de datos que añadir a las inicialmente analizadas


2)Aceptar como primer entregable un datamart clave basado en clientes, como el de rentabilidad por ser uno de los más atractivos y deseados por los usuarios

1)En vez de hablar con los usuarios de negocio finales eliges interlocutores de alto nivel, expertos o consultores que te resumen las necesidades de los usuarios

Diseño físico:

Componentes mas importantes

• Table Space: Se le indica al motor de base de datos el espacio en donde se creara cierto número de tablas para dividir la ubicación física. Es conveniente utilizar diferentes table spaces para las tablas de hechos y las tablas de dimensiones.

• Indices: Es conveniente desactivarlos durante el proceso de ETL y volverlos a activar cuando se requiera explotar la información.

• Vistas materializadas: Son vistas que se actualizan periódicamente, esto es conveniente ya que cuando una vista normal arroja una gran cantidad de datos puede llegar a afectar al performance del servidor estar ejecutándola continuamente.

Modelos de Data Warehouse

Modelos de Data Warehouse

Los diferentes autores están de acuerdo en los modelos, la discrepancia consiste en la metodología

Modelo de Estrella:

• Consiste en una tabla principal denominada hechos y de varias tablas con datos complementarios denominadas de dimensiones
• En este tipo de modelos es necesario validar si se manejan PK, debido a que los datos vaciados en las tablas ya pasan por un proceso previo de validación .

3ra Forma normal:

•  Aplicable en diferentes modelos
•  No se manejo el concepto de una sola tabla de hechos
•  El Drill Down es muy poderoso.
•  Se tienen que dar muchos saltos para obtener la información
•  Es prácticamente una copia de la base OLTP.
•  Es muy cuestionable.

Copo de Nieve. 

• Una tabla de hechos y modelos de dimensiones.
• Se manejan tablas de dimensiones con modelos de E/R con otras tablas para mayor detalle.
• Se pueden manejar mas de una tabla de hechos pero de manera muy controlada, en caso de crecer demasiado es recomendable hacer otro DW de la 2da tabla de hechos.

  

Conceptos de Data Warehouse (Continuación)

Conceptos de Data Warehouse (Continuación)

 

 

Durante el diseño de la tabla de hecho es muy importante validar hasta donde se llega con la des normalización, ya que no debemos llenarla con campos que no serán necesarios o que podrían ser incluidos una tabla de dimensiones, existente o nueva.

 

Diseño conceptual
 
Internamente un DW esta d compuesto de los siguientes componentes

• Datos específicos:  Únicamente los que necesitemos y hayamos encontrado durante los requerimientos.
• Relaciones: Entre la tabla de Hechos y las tablas de relaciones.
•  Transformación: Proceso ETL, mediante el cual se transforman y cargan los datos provenientes de las distintas fuentes.
• Periodos de actualización

Dentro del DW se manejan los siguientes modelos

• Estrella
• 3fn
• Copo de nieve

 

Conceptos de Datawarehouse

El administrador de un Data Warehouse debe tener las siguientes características: 

• Esta buscando usuarios potenciales
• Elige el mejor modelo y el conjunto de datos para aplicarlo
• Asegurar consistencia e integridad de los datos 
• Monitorear los resultados.

Un esquema de Data Warehouse común tiene los siguientes componentes

 Sistemas fuente -> ETL -> DW -> reportes

ETL: Es el proceso que se hace para extraer y transformar los datos para cargarlos en otra fuente. Durante este procesa se reportar diferencias y problemas en la congruencia de los datos.

Consejos para el proceso de ETL:

• Desactivar los triggers, in dices y de preferencia usar niveles de aislamiento.
• Desactivar índices
• Bloquear usuarios
• Re indexar
• Reabrir los puertos.

Datamart: Es un Data Warehouse pequeño, puede ser una región o un periodo de tiempo. Sirve también para distribuir la carga de trabajo.

OLAP vs OLTP

Oltp:  es una base de datos transaccional para  control operacional,diseñada para las siguientes operaciones:

 Insert

Update

Delete

Selects de bajo volumen. 

Olap: Base de datos de consulta en donde se visualiza la operación, es multidimensional y contiene la verdad de los datos. En esta base de datos se realizan selects de alto volumen

Datawarehouse: definiciones según los distintos autores.

Curtis: Es una base de datos relacional diseñada parara consulta y análisis. 

Kingball: Es una copia de los fatos transaccionales , que se estructura pára consulta y análisis.

Inmon: es considerado el papa de los dadtawarehouse, define las siguientes características:

 Orientado a temas. 

Base de datos integrada. 

No volatil. 

Variante en el tiempo

Antecedentes

Antecedentes del Datawarehouse

1960's

• Nacen las  tarjetas perforadas y cintas magnéticas en donde el acceso se hacia de forma secuencial.

1970 's

• Nacen los discos de acceso directo (dasd). 
• Bases de datos jerarquicas y reticulares. 
• Primeras arquitecturas de oltp trabajando en linea. 
• Sistemas cliente, nacen las terminales tontas.

1980's. 

• Surgen las pc y emulaciones. 
• Nace 4gl que es sql con oltp y olap. 
• Toman importancia los administradores de bases de datos, esto debido a que se empiezan a  separar los datos de las aplicaciones.

1990's 

• Surgen problemas por hacer consulta en la misma base de datos en la cual se hacen las transacciones, por lo que surge la necesidad de separar las base de datos en olap y oltp.

Caracteristicas de OLAP y OLTP

OLTP:

•  Dato primitivo. 
• Se conserva a nivel de detalle cada operación.
•  Actualizable.
• Refleja el valor actual.
•  Procesos repetitivos.

OLAP: 

• Datos derivados.
• se pierde el detalle por que se enfoca en estadística, es acumulable no actualizable, heuristicos

Estrategico, tactico, operativo, interorganizacional