Anda di halaman 1dari 21

Arquitectura de una solución BI.

1.¿Qué es arquitectura de una solucion BI?

Una solución de Business Intelligence parte de los sistemas de origen de una organización (bases
de datos, ERPs, ficheros de texto…), sobre los que suele ser necesario aplicar una transformación
estructural para optimizar su proceso analítico.

Para ello se realiza una fase de extracción, transformación y carga (ETL) de datos. Esta etapa
suele apoyarse en un almacén intermedio, llamado ODS, que actúa como pasarela entre los
sistemas fuente y los sistemas destino (generalmente un datawarehouse), y cuyo principal
objetivo consiste en evitar la saturación de los servidores funcionales de la organización.

La información resultante, ya unificada, depurada y consolidada, se almacena en un


datawarehouse corporativo, que puede servir como base para la construcción de distintos
datamarts departamentales. Estos datamarts se caracterizan por poseer la estructura óptima
para el análisis de los datos de esa área de la empresa, ya sea mediante bases de datos
transaccionales (OLTP) o mediante bases de datos analíticas (OLAP).

Los datos albergados en el datawarehouse o en cada datamart se explotan utilizando


herramientas comerciales de análisis, reporting, alertas... etc. En estas herramientas se basa
también la construcción de productos BI más completos, como los sistemas de soporte a la
decisión (DSS), los sistemas de información ejecutiva (EIS) y los cuadros de mando (CMI) o
Balanced Scorecard (BSC).

1.1.¿Qué es un datawarehouse?

Un Datawarehouse es una base de datos corporativa que se caracteriza por integrar y depurar
información de una o más fuentes distintas, para luego procesarla permitiendo su análisis desde
infinidad de perspectivas y con grandes velocidades de respuesta. La creación de un
datawarehouse representa en la mayoría de las ocasiones el primer paso, desde el punto de
vista técnico, para implantar una solución completa y fiable de Business Intelligence.

La ventaja principal de este tipo de bases de datos radica en las estructuras en las que se
almacena la información (modelos de tablas en estrella, en copo de nieve, cubos relacionales…
etc.). Este tipo de persistencia de la información es homogénea y fiable, y permite la consulta y
el tratamiento jerarquizado de la misma (siempre en un entorno diferente a los sistemas
operacionales).

Por último, destacar que para comprender íntegramente el concepto de datawarehouse, es


importante entender cuál es el proceso de construcción del mismo, denominado ETL (Extracción,
Transformación y Carga), a partir de los sistemas operaciones de una compañía:

• Extracción: obtención de información de las distintas fuentes tanto internas como externas.

• Transformación: filtrado, limpieza, depuración, homogeneización y agrupación de la


información.

• Carga: organización y actualización de los datos y los metadatos en la base de datos.


1.2.¿Qué es Data Mart?

Un Datamart es una base de datos departamental, especializada en el almacenamiento de los


datos de un área de negocio específica. Se caracteriza por disponer la estructura óptima de
datos para analizar la información al detalle desde todas las perspectivas que afecten a los
procesos de dicho departamento. Un datamart puede ser alimentado desde los datos de un
datawarehouse, o integrar por si mismo un compendio de distintas fuentes de información.

Por tanto, para crear el datamart de un área funcional de la empresa es preciso encontrar la
estructura óptima para el análisis de su información, estructura que puede estar montada
sobre una base de datos OLTP, como el propio datawarehouse, o sobre una base de datos
OLAP. La designación de una u otra dependerá de los datos, los requisitos y las características
específicas de cada departamento. De esta forma se pueden plantear dos tipos de datamarts:
DatamartOLAP y DatamartOLTP.

Podemos entender un Data Mart como un subconjunto de los datos del Data Warehouse con
el objetivo de responder a un determinado análisis, función o necesidad y con una población
de usuarios específica. Al igual que en un data warehouse, los datos están estructurados en
modelos de estrella o copo de nieve y un data mart puede ser dependiente o independiente
de un data warehouse. Por ejemplo, un posible usos sería para el data mining.¿Qué diferencia
existe entonces entre un data mart y un data warehouse? Su alcance. El data mart está
pensado para cubrir las necesidades de un grupo de trabajo o de un determinado
departamento dentro de la organización. Es el almacén natural para los datos
departamentales. En cambio, el ámbito del data warehouse es la organización en su conjunto.
Es el almacén natural para los datos corporativos comunes.
1.3.El proceso ETL

Los procesos ETL son una parte de la integración de datos, pero es un elemento
importante cuya función completa el resultado de todo el desarrollo de la cohesión de
aplicaciones y sistemas.

La palabra ETL corresponde a las siglas en inglés de:

• Extraer: extract.
• Transformar: transform.
• Y Cargar: load.

Con ello, queremos decir que todo proceso ETL consta precisamente de estas tres fases:
extracción, transformación y carga. Vamos a definir en qué consisten cada una de estas
fases.

a)Fase de Extracción
Para llevar a cabo de manera correcta el proceso de extracción, primera fase del ETL, hay
que
seguir los siguientes pasos:

● Extraer los datos desde los sistemas de origen.


● Analizar los datos extraídos obteniendo un chequeo.
● Interpretar este chequeo para verificar que los datos extraídos cumplen la pauta o
estructura que se esperaba. Si no fuese así, los datos deberían ser rechazados.
● Convertir los datos a un formato preparado para iniciar el proceso de transformación

Además, uno de las prevenciones más importantes que se deben tener en cuenta durante
el proceso de extracción sería el exigir siempre queesta tarea cause un impacto mínimo en
el sistema de origen. Este requisito se basa en la práctica ya que, si los datos a extraer
son muchos, el sistema de origen se podría ralentizar e incluso colapsar, provocando que
no pudiera volver a ser utilizado con normalidad para su uso cotidiano.

b)Fase de Transformación
La fase de transformación de un proceso de ETL aplica una serie de reglas de negocio o
funciones, sobre los datos extraídos para convertirlos en datos que serán cargados. Estas
directrices pueden ser declarativas, pueden basarse en excepciones o restricciones pero,
para potenciar su pragmatismo y eficacia, hay que asegurarse de que sean:

● Declarativas.
● Independientes.
● Claras.
● Inteligibles.
● Con una finalidad útil para el negocio.

c)Proceso de Carga
En esta fase, los datos procedentes de la fase anterior (fase de transformación) son
cargados en el sistema de destino. Dependiendo de los requerimientos de la organización,
este proceso puede abarcar una amplia variedad de acciones diferentes.

Existen dos formas básicas de desarrollar el proceso de carga:

● Acumulación simple: esta manera de cargar los datos consiste en realizar un resumen
de
todas las transacciones comprendidas en el período de tiempo seleccionado y transportar
el resultado como una única transacción hacia el data warehouse, almacenando un valor
calculado que consistirá típicamente en un sumatorio o un promedio de la magnitud
considerada. Es la forma más sencilla y común de llevar a cabo el proceso de carga.

● Rolling: este proceso sería el más recomendable en los casos en que se busque
mantener
varios niveles de granularidad. Para ello se almacena información resumida a distintos
niveles, correspondientes a distintas agrupaciones de la unidad de tiempo o diferentes
niveles jerárquicos en alguna o varias de las dimensiones de la magnitud almacenada (por
ejemplo, totales diarios, totales semanales, totales mensuales, etc.).

Sea cual sea la manera elegida de desarrollar este proceso, hay que tener en cuenta que
esta
fase interactúa directamente con la base de datos de destino y, por eso, al realizar esta
operación se aplicarán todas las restricciones que se hayan definido en ésta. Si están bien
definidas, la calidad de los datos en el proceso ETL estará garantizada.

1.3.1.Aplicaciones de los procesos ETL

Gracias a los procesos ETL es posible que cualquier organización:

• Mueva datos desde una o múltiples fuentes.


• Reformatee esos datos y los limpie, cuando sea necesario.
• Los cargue en otro lugar como una base de datos, un data mart o un data
warehouse.
• Una vez alojados en destino, esos datos se analicen.
• O, cuando ya están cargados en su ubicación definitiva, se empleen en otro sistema
operacional, para apoyar un proceso de negocio.
No obstante, las herramientas ETL no tienen por qué utilizarse sólo en entornos de Data
Warehousing o construcción de un Data Warehouse, sino que pueden ser útiles para
multitud de propósitos, como por ejemplo:

• Tareas de Bases de datos: que también se utilizan para consolidar, migrar y


sincronizar
bases de datos operativas.
• Migración de datos entre diferentes aplicaciones por cambios de versión o cambio de
aplicativos.
• Sincronización entre diferentes sistemas operacionales (por ejemplo, entre nuestro
entorno
ERP y la web de ventas).
• Consolidación de datos: sistemas con grandes volúmenes de datos que son
consolidados
en sistemas paralelos, ya sea para mantener históricos o para llevar a cabo procesos de
borrado en los sistemas originales.
• Interfases de datos con sistemas externos: como el envío de información a clientes o
proveedores. También servirían para la recepción, proceso e integración de la información
recibida.
• Interfases con sistemas Frontoffice: serían interfases de subida/bajada con sistemas
de
venta.
• Otros cometidos: como la actualización de usuarios a sistemas paralelos o la
preparación de procesos masivos (tipo mailings o newsletter).

1.3.2.Otros usos de los procesos ETL


Los procesos ETL no sólo se utilizan cuando sobreviene la aparición de nuevas
aplicaciones que se han de incorporar a las rutinas de la organización, sino que también es
frecuente emplearlas para la integración con sistemas heredados.

Cuando se habla de sistemas heredados se está haciendo referencia a las aplicaciones


antiguas que existen en el entorno de la empresa. Muchas veces, estos sistemas se deben
integrar con nuevos aplicativos, por ejemplo con ERPs.

La principal dificultad que puede presentarse en este tipo de situaciones es que la


tecnología utilizada en estas aplicaciones antiguas complica la integración con los nuevos
programas.

1.4.¿Cómo y porqué implementar una arquitectura BI?

El trato de lo datos, información y creación de conocimiento posterior son


claves para la toma de decisiones de la empresa contemporánea. En este
escenario es donde el Business Intelligence está consolidando su presencia.
Sobre todo en las empresas que ya se encuentran en un estadio avanzado de
transformación digital.

Para integrar una arquitectura BI es necesario seguir los siguientes pasos:


1- Identificar la información que se quiere obtener. Es decir, cuáles son las
preguntas a las que se quiere dar respuesta con el sistema BI.

2- Identificar los orígenes de datos: ¿De dónde obtenemos los datos a


analizar? ¿Del CRM, del ERP, de una combinación de sistemas? El sistema
origen debe proporcionar los datos para responder a las preguntas
identificadas en el primer punto.

3- Crear un modelo de datos. En base a la información disponible, y a lo que


se pretende analizar, se debe crear un modelo de datos que permita obtener el
conocimiento deseado a partir de los datos disponibles. El proceso de
modelado es un análisis lógico previo al desarrollo, en el que se diseña la
estructura de datos y las relaciones jerárquicas entre los elementos

4- Crear infraestructura de base de datos (DWH) y proceso de carga (ETL).


Las herramientas BI no suelen consultar los datos de las bases de datos
transaccionales, para evitar bloqueos o sobrecargas. Es por este motivo que se
construye un almacén de datos (Datawarehouse o DWH) con una estructura
adecuada para el modelo de datos definido. En este DWH se cargará la
información que se extrae de los sistemas origen. Esta extracción y carga se
realiza con procesos ETL (del inglés Extract, Transform, Load), que extraen los
datos del sistema origen, los procesan (limpiar datos, regularizar nombres de
diferentes orígenes, etc.) y los cargan en el DWH.

5- Implementar el modelo de datos, el sistema de reporting y cuadros de


mando. Una vez se ha definido el DWH y ya contiene datos, se puede utilizar
una herramienta de BI para plasmar el modelo de datos y crear reportes o
cuadros de mando con la información requerida para dar las respuestas
buscadas.

2.1.Metodología de Kimball

La visión de Kimball se basa en que son los procesos de negocio los que deben de
marcar la forma en la que diseñamos el datawarehouse. Admite un punto de partida en
que ya existen datos más o menos organizados en datamarts, y que estos son la base del
futuro datawarehouse.

Para Kimball lo más importante es que el cálculo de los datos que servirá para la toma
de decisiones sea rápido, por lo que estructura los datos del datawarehouse
siguiendo patrones dimensionales. Esto suele mejorar mucho su rendimiento a la
hora de realizar consultas y además organiza los datos de una forma más intuitiva y
natural para los usuarios.
Enfoque Kimball - Arquitectura Bus del DW

La Metodología Kimball, es una metodología empleada para la construcción de un almacén de


datos (data warehouse, DW) que no es mas que, una colección de datos orientada a un
determinado ámbito (empresa, organización, etc.), integrado, no volátil y variable en el
tiempo, que ayuda a la toma de decisiones en la entidad en la que se utiliza.

La metodología se basa en lo que Kimball denomina Ciclo de Vida Dimensional del Negocio
(Business Dimensional Lifecycle). Este ciclo de vida del proyecto de DW, está basado en cuatro
principios básicos:

 Centrarse en el negocio
 Construir una infraestructura de información adecuada
 Realizar entregas en incrementos significativos (este principio consiste en crear el
almacén de datos (DW) en incrementos entregables en plazos de 6 a 12 meses, en este
punto, la metodología se parece a las metodologías ágiles de construcción de
software)
 Ofrecer la solución completa (En este se punto proporcionan todos los elementos
necesarios para entregar valor a los usuarios de negocios, para esto ya se debe tener
un almacén de datos bien diseñado, se deberán entregar herramientas de consulta ad
hoc, aplicaciones para informes y análisis avanzado, capacitación, soporte, sitio web y
documentación).
Figura: ciclo de vida de la construcción de un solución DW/BI.

4.1. Planificación del Proyecto

En este proceso se determina el propósito del proyecto de DW/BI, sus objetivos específicos y
el alcance del mismo, los principales riesgos y una aproximación inicial a las necesidades de
información. Esta tarea incluye las siguientes acciones típicas de un plan de proyecto:

 Definir el alcance (entender los requerimientos del negocio).


 Identificar las tareas
 Programar las tareas
 Planificar el uso de los recursos.
 Asignar la carga de trabajo a los recursos
 Elaboración de un documento final que representa un plan del proyecto.

Además en esta parte definimos cómo realizar la administración o gestión de esta subfase que
es todo un proyecto en si mismo, con las siguientes actividades:

 Monitoreo del estado de los procesos y actividades.


 Rastreo de problemas
 Desarrollo de un plan de comunicación comprensiva que direccione la empresa y las
áreas de TI

4.2 Definición de Requerimientos del Negocio

La definición de requerimientos, es un proceso de entrevistar al personal de negocio y técnico,


aunque siempre conviene, tener un poco de preparación previa. En esta tarea, se debe
aprender sobre el negocio, los competidores, la industria y los clientes del mismo. Se debe dar
una revision a todos los informes posibles de la organización; rastrear los documentos de
estrategia interna; entrevistar a los empleados, analizar lo que se dice en la prensa acerca de la
organización, la competencia y la industria y se deben conocer los términos y la terminología
del negocio.
Se sugiere entrevistar al personal que se encuentra en los cuatro grupos que se mencionan a
continuación:

 El directivo responsable de tomar las decisiones estratégicas.


 Los administradores intermedios y de negocio responsables de explorar alternativas
estratégicas y aplicar decisiones
 El personal de sistemas, si existe (estas son las personas que realmente saben qué
tipos de problemas informáticos y de datos existen en la organización)
 El personal que se entrevista por razones políticas.

Entre las tareas antes descritas, existe una flecha bidireccional, esto indica que los
requerimientos del negocio son el soporte inicial de las tareas subsiguientes, también tiene
influencia en el plan de proyecto.

Si avanzamos por el camino central del diagraman, encontramos las tareas asociadas al área de
Datos, en esta, diseñaremos e implementaremos el modelo dimensional, y desarrollaremos el
subsistema de Extracción, Transformación y Carga (Extract, Transformation, and Load - ETL)
para cargar el DW. Las tareas pertenecientes al área, se describen a continuación:

4.3 Modelado Dimensional

Es un proceso dinámico y altamente iterativo. Comienza con un modelo dimensional de alto


nivel obtenido a partir de los procesos priorizados y descritos en la tarea anterior, y El proceso
iterativo consiste en cuatro pasos:

a). Elegir el proceso de negocio: que consiste en, elegir el área a modelizar. Esta es una
decisión de la dirección, y depende fundamentalmente del análisis de requerimientos y de los
temas analíticos anotados en la etapa anterior.

b). Establecer el nivel de granularidad: La granularidad significa especificar el nivel de detalle.


La elección de la granularidad depende de los requerimientos del negocio y lo que es posible a
partir de los datos actuales. La sugerencia general es comenzar a diseñar el DW al mayor nivel
de detalle posible, ya que se podrían realizar agrupamientos posteriores, al nivel deseado.

c). Elegir las dimensiones: Las dimensiones surgen naturalmente de las discusiones del equipo,
y facilitadas por la elección del nivel de granularidad y de la matriz de procesos/dimensiones
(que se realiza en la tarea 4.2) Las tablas de dimensiones tienen un conjunto de atributos
(generalmente textuales) que brindan una perspectiva o forma de análisis sobre una medida
en una tabla hechos. Una forma de identificar las tablas de dimensiones es que sus atributos
son posibles candidatos para ser encabezado en los informes, tablas pivot, cubos, o cualquier
forma de visualización, unidimensional o multidimensional.

d). Identificar medidas y las tablas de hechos: Este paso, consiste en identificar las medidas
que surgen de los procesos de negocios. Una medida es un atributo (campo) de una tabla que
se desea analizar, sumando o agrupando sus datos y usando los criterios de corte conocidos
como dimensiones. Las medidas habitualmente se vinculan con el nivel de granularidad del
punto 2, y se encuentran en tablas que denominamos tablas de hechos (fact en inglés). Cada
tabla de hechos tiene como atributos una o más medidas de un proceso organizacional, de
acuerdo a los requerimientos. Un registro contiene una medida expresada en números, como
ser cantidad, tiempo, dinero, etc., sobre la cual se desea realizar una operación de agregación
(promedio, conteo, suma, etc.) en función de una o más dimensiones. La granularidad, en este
punto, es el nivel de detalle que posee cada registro de una tabla de hechos.
4.4. Diseño Físico

En esta tarea, se contestan las siguientes preguntas:

¿Cómo puede determinar cuán grande será el sistema de DW/BI?

¿Cuáles son los factores de uso que llevarán a una configuración más grande y más compleja?

¿Cómo se debe configurar el sistema?

¿Cuánta memoria y servidores se necesitan? ¿Qué tipo de almacenamiento y procesadores?

¿Cómo instalar el software en los servidores de desarrollo, prueba y producción?

¿Qué necesitan instalar los diferentes miembros del equipo de DW/BI en sus estaciones de
trabajo?

¿Cómo convertir el modelo de datos lógico en un modelo de datos físicos en la base de datos
relacional?

¿Cómo conseguir un plan de indexación inicial?

¿Debe usarse la partición en las tablas relacionales?

4.5. Diseño e Implementación del subsistema de Extracción, Transformación y Carga (ETL)

El subsistema de Extracción, Transformación y Carga (ETL) es la base sobre la cual se alimenta


el Data warehouse. Si se diseña adecuadamente, puede extraer los datos de los sistemas de
origen de datos, aplicar diferentes reglas para aumentar la calidad y consistencia de los
mismos, consolidar la información proveniente de distintos sistemas, y finalmente cargar
(grabar) la información en el DW en un formato acorde para la utilización por parte de las
herramientas de análisis.

4.6. Implementación

La implementación representa la convergencia de la tecnología, los datos y las aplicaciones de


usuarios finales accesible desde el escritorio del usuario del negocio. Existen varios factores
extras que aseguran el correcto funcionamiento de todas estas piezas, entre ellos se
encuentran la capacitación, el soporte técnico, la comunicación y las estrategias de feedback.

4.7 Mantenimiento y Crecimiento del Data Warehouse

Para administrar el entorno del Data Warehouse existente es importante enfocarse en los
usuarios de negocio, los cuales son el motivo de su existencia, además de gestionar
adecuadamente las operaciones del Data Warehouse, medir y proyectar su éxito y
comunicarse constantemente con los usuarios para establecer un flujo de retroalimentación,
En esto consiste el Mantenimiento. Finalmente, es importante sentar las bases para el
crecimiento y evolución del Data Warehouse en donde el aspecto clave es manejar el
crecimiento y evolución de forma iterativa utilizando el Ciclo de Vida propuesto, y establecer
las oportunidades de crecimiento y evolución en orden por nivel prioridad.

Si avanzamos por el camino inferior del diagraman, encontramos las tareas asociadas al área
Aplicaciones de Inteligencia de Negocios, en esta ruta se encuentran tareas en las que
diseñamos y desarrollamos las aplicaciones de negocios para los usuarios finales. Las tareas
pertenecientes al área, se describen a continuación:
4.8 Especificación de aplicaciones de BI

En está tarea se proporciona, a una gran comunidad de usuarios una forma más estructurada y
por lo tanto, más fácil, de acceder al almacén de datos. Se proporciona este acceso
estructurado a través de lo que llamamos, aplicaciones de inteligencia de negocios (Business
Intelligence Aplications). Las aplicaciones de BI son la cara visible de la inteligencia de
negocios: los informes y aplicaciones de análisis proporcionan información útil a los usuarios.
Las aplicaciones de BI incluyen un amplio espectro de tipos de informes y herramientas de
análisis, que van desde informes simples de formato fijo, a sofisticadas aplicaciones analíticas
que usan complejos algoritmos e información del dominio. Kimball divide a estas aplicaciones
en dos categorías basadas en el nivel de sofisticación, y les llama:

a). Informes estándar: son informes relativamente simples, de formato predefinido, y


parámetros de consulta fijos, proporcionan a los usuarios un conjunto básico de información
acerca de lo que está sucediendo en un área determinada de la empresa y se utilizan día a día.

b). Aplicaciones analíticas: Son más complejas que los informes estándar. Estas aplicaciones
pueden incluir algoritmos y modelos de minería de datos, que ayudan a identificar
oportunidades o cuestiones subyacentes en los datos, y el usuario puede pedir cambios en los
sistemas transaccionales basándose en los conocimientos obtenidos del uso de la aplicación de
BI. Algunas aplicaciones analíticas comunes incluyen:

 Análisis de la eficacia de la promociones


 Análisis de rutas de acceso en un sitio Web
 Análisis de afinidad de programas
 Planificación del espacio en espacios comerciales
 Detección de fraudes
 Administración y manejo de categorías de productos

Por ultimo, en el camino superior, encontramos las tareas asociadas al área Tecnología en esta
ruta, se encuentran las tareas relacionadas con software específico, por ejemplo, Microsoft
SQL Analysis Services, etc. Las tareas pertenecientes al área, se describen a continuación:

4.9 Diseño de la Arquitectura Técnica

El área de arquitectura técnica cubre los procesos y herramientas que se aplican a los datos. En
el área técnica existen dos conjuntos que tienen distintos requerimientos, brindan sus propios
servicios y componentes de almacenaje de datos, por lo que se consideran cada uno aparte: El
back room (habitación trasera) y el front room (habitación frontal). El back room es el
responsable de la obtención y preparación de los datos, por lo que también se conoce como
adquisición de datos y el front room es responsable de entregar los datos a la comunidad de
usuario y también se le conoce como acceso de datos.

2.1.La filosofía del enfoque de Kimball


Su filosofía se centra en que, en la mayoría de las organizaciones, la construcción
de un datawarehouse se origina por el interés y esfuerzo de un departamento. Es
por esto por lo que en su primera versión este datawarehouse no es más que
un datamartdepartamental.
A medida que otros departamentos necesiten sus propios datamarts, éstos se irán
combinando con el primero manteniendo una metodología de estandarización
mediante lo que Kimball denomina “dimensiones conformadas”, que serán las
dimensiones comunes entre los diferentes departamentos. La clave radica en que
estas dimensiones han de ser compartidas por los distintos datamarts que existan
en la organización, garantizándose así la integridad de los mismos y dando lugar al
conglomerado de estructuras que para Kimball conforman el datawarehouse.

Para lograr este resultado, es importante que estas dimensiones conformadas


tengan un diseño consistente y apto para todos los datamarts, de forma que al
crearse uno nuevo, reutilice las dimensiones ya definidas, pudiendo incluir o no
otras dimensiones nuevas.

La principal ventaja de este enfoque de almacén de datos es que, al estar formado


por pequeños datamarts estructurados en modelos de datos dimensionales
(esquemas de estrella o copo de nieve), especialmente diseñados para la consulta
y generación de informes, el datawarehouse al completo puede ser explotado
directamente por las herramientas de reporting y análisis de datos sin la necesidad
de estructuras intermedias.

Arquitectura Kimball – modelo dimensional

En cuanto a las cuestiones sobre la granularidad, a pesar de que este tipo


de datawarehouse suele presentar los datos agregados en base a las consultas e
informes que haya que generar, Kimball insiste en la necesidad de que estas
agregaciones estén complementadas con datos a mayor nivel de detalle.

El argumento es que las preguntas de negocio que puedan llegar a hacer los
usuarios son impredecibles, de manera que el datawahouse tiene que estar
preparado para dar respuesta a todas ellas, garantizando la exploración de los
datos y la navegación a través de jerarquías desde datos agregados hasta
información desagregada.
A este tipo de arquitectura Kimball lo denomina como “Data Warehouse Bus
Architecture” y los cuatro pasos fundamentales que se han de seguir para construir
este tipo de base de datos son, en primer lugar, la identificación del proceso de
negocio que se pretenda estudiar, la definición de la granularidad de los datos,
la selección de las dimensiones y atributos y, por último, la identificación de los
hechos o métricas.

El esquema de arquitectura en base a los fundamentos de Ralph Kimball sería el


de la siguiente imagen:

Arquitectura Kimball

3.Modelo dimensional

Una base de datos con “modelo dimensional” es una base de datos que tiene una
estructura adecuada para resolver consultas analíticas. Se trata de modelos
sencillos que aseguran unos buenos tiempos de respuesta, y que se corresponden
bastante con el lenguaje de negocio de los usuarios. Las herramientas de BI se
conectan al “modelo dimensional” del DWH. Típicamente, se implementa con
alguna de estas dos opciones:
 O pc ió n A: E n u na b ase de dato s rel ac io n a l.
 O pc ió n B : E n u na b ase de dato s m ult i dim en s io n a l.

En el caso de que utilices una base de datos relacional (esto es: una base de datos
normal y corriente de las de toda la vida), construirás el “modelo dimensional”
utilizando una estructura en estrella, o una estruc tura en copo de nieve.
Y si utilizas una base de datos multidimensional, construirás “cubos”, y utilizarás
una tecnología específica para estos menesteres (con sus ventajas e
inconvenientes).

Se llama “modelo dimensional”, porque para su creación/defin ición se hace un


estudio sobre los datos de la empresa, identificando las “dimensiones”, y
analizando como las dimensiones se relacionan entre sí (creando jerarquías), y
como se relacionan con las tablas de hecho (creando “estrellas” o “cubos”).

En resumen, el “modelo dimensional” es el modo óptimo de organizar los datos


en los sistemas de Business Intelligence, y puede hacerse mediante bases de
datos relacionales (ROLAP), o utilizando bases de datos multidimensionales
(MOLAP).

3.1.¿Cómo se construye el modelo dimensional?


El modelo tridimensional se construye sobre un esquema de estrella, con dimensiones de
la tabla de hechos23 para construir el esquema, el siguiente modelo de diseño se utiliza:
1. Escoger el proceso de negocio
2. Declarar el "grain"
3. Identificar las dimensiones
4. Identificar los hechos
Escoger el proceso de negocio
El proceso de modelización dimensional se basa en un método de diseño de 4 pasos que
ayuda a asegurar la facilidad de uso del modelo dimensional y el uso del almacén de
datos. Los fundamentos del diseño se basan en el proceso de negocio real que debe cubrir
el almacén de datos. Por lo tanto el primer paso en el modelo es describir el proceso de
negocio en él se basa el modelo. Esto podría ser por ejemplo una situación de ventas en
una tienda al por menor. Para describir el proceso de negocio, se puede optar por hacer
esto en texto plano o utilizar Notación de Modelado de Procesos de Negocio (BPMN en
inglés) u otras guías de diseño, como el Lenguaje Unificado de Modelado (UML en inglés).
Declarar el "grain"
Después de describir el Proceso de Negocio, el siguiente paso en el diseño es declarar el
"grain" del modelo. El "grain" del modelo es la descripción exacta de lo que el modelo
dimensional debería concentrarse. Para aclarar lo que significa el "grain", usted debe
escoger el proceso central y describirlo con una sola oración. Además el "grain" (oración)
es a lo que se le va a construir sus dimensiones y tabla de hechos. Puede que le resulte
necesario volver a este paso para alterar el "grain" debido a nueva información obtenida en
lo que su modelo supone entregar.
Identificar las dimensiones
El tercer paso en el proceso de diseño es definir las dimensiones del modelo. Las
dimensiones deben ser definidas dentro del "grain" de la segunda etapa del proceso de
modelado dimensional de 4 pasos. Las dimensiones son la base de la tabla de hechos, y
es donde se recogen los datos de la tabla de hechos. Normalmente las dimensiones son
sustantivos, como fecha, tienda, inventario, etc. Estas dimensiones son donde se
almacenan todos los datos. Por ejemplo, la dimensión fecha podría contener datos tales
como año, mes y día de la semana.
Identificar los hechos
Después de definir las dimensiones, el siguiente paso en el proceso es crear las llaves de
la tabla de hechos. Este paso es identificar los hechos numéricos que poblarán cada fila de
la tabla de hechos. Este paso está estrechamente relacionado con los usuarios de negocio
del sistema, ya que es donde consiguen el acceso a los datos almacenados en el almacén
de datos. Por lo tanto la mayor parte de las filas de la tabla de hecho son cifras numéricas,
aditivos tales como cantidad o costo por unidad, etc.

4.Metodología inmon

Bill Inmon ve la necesidad de transferir la información de los diferentes OLTP (Sistemas


Transaccionales) de las organizaciones a un lugar centralizado donde los datos puedan ser
utilizados para el analisis (sería el CIF o Corporate Information Factory). Insiste ademas en que
ha de tener las siguientes características:

 Orientado a temas.- Los datos en la base de datos están organizados de manera que
todos los elementos de datos relativos al mismo evento u objeto del mundo real
queden unidos entre sí.
 Integrado.- La base de datos contiene los datos de todos los sistemas operacionales de
la organización, y dichos datos deben ser consistentes.

 No volátil.- La información no se modifica ni se elimina, una vez almacenado un dato,


éste se convierte en información de sólo lectura, y se mantiene para futuras consultas.

 Variante en el tiempo.- Los cambios producidos en los datos a lo largo del tiempo
quedan registrados para que los informes que se puedan generar reflejen esas
variaciones.

La información ha de estar a los máximos niveles de detalle. Los Dw departamentales o


datamarts son tratados como subconjuntos de este Dw corporativo, que son construidos para
cubrir las necesidades individuales de analisis de cada departamento, y siempre a partir de
este Dw Central (del que también se pueden construir los ODS ( Operational Data Stores ) o
similares).

Enfoque Inmon - DW Corporativo

El enfoque Inmon tambien se referencia normalmente como Top-down. Los datos son
extraidos de los sistemas operacionales por los procesos ETL y cargados en las areas de stage,
donde son validados y consolidados en el DW corporativo, donde ademas existen los llamados
metadatos que documentan de una forma clara y precisa el contenido del DW. Una vez
realizado este proceso, los procesos de refresco de los Data Mart departamentales obtienen la
información de el, y con las consiguientes transformaciones, organizan los datos en las
estructuras particulares requeridas por cada uno de ellos, refrescando su contenido.

La metodologia para la construcción de un sistema de este tipo es la habitual para construir


un sistema de información, utilizando las herramientas habituales (esquema Entidad
Relacion, DIS (Data Item Sets, etc). Para el tratamiento de los cambios en los datos, usa
la Continue and Discrete Dimension Management (inserta fechas en los datos para
determinar su validez para las Continue Dimension o bien mediante el concepto de snapshot o
foto para las Discrete Dimension).

Al tener este enfoque global, es mas dificil de desarrollar en un proyecto sencillo (pues
estamos intentando abordar el “todo”, a partir del cual luego iremos al “detalle”).
4.1.El enfoque de Inmon
Lo primero a la hora de desarrollar del datawarehouse será establecer la estructura
de datos en 3FN, perfectamente normalizada y limpia. Los datos que se insertarán
en esta estructura generalmente procederán de un “área de carga” en la que los
datos son depurados antes de pasar a la estructura normalizada del
datawarehouse.

A partir de esa estructura, se pueden establecer una serie de datamarts que


agrupen de una forma más lógica (y si se quiere multidimensional) la información
del datawarehouse principal. Como se puede observar, esta forma de trabajar es
mucho más organizada pero menos flexible que la anterior, ya que aquí es la
estructura y la normalización de los datos lo que marcará la pauta a la hora de
trabajar en vez de que sean los procesos existentes de negocio.

Para ir adentrándonos poco a poco en sus principales diferencias y poder llegar a


determinar qué opción es la más adecuada en nuestros proyectos, en esta entrada
expondré las características más destacadas del enfoque de Inmon.
Para él, un DataWarehouse ha de entenderse como un almacén de datos único y
globalpara toda la empresa.

Un repositorio que centralice los datos de los diferentes sistemas


operacionales de las organizaciones para que éstos queden validados e
integrados en una única base de datos.
En este modelo, la premisa es que la información se almacene al máximo nivel de
detalle(garantizando la futura exploración de los datos), permaneciendo invariable
y no volátil, de manera que los cambios que sufran los datos a lo largo del tiempo
queden registrados sin que puedan modificarse o eliminarse.

Claves de la arquitectura
Estas son las claves fundamentales de la arquitectura defendida por Inmon,
conocida como ‘Corporate Information Factory (CIF)’, donde
el DataWarehouse centraliza todos los datos de la compañía para alimentar, a
continuación, pequeños DataMarts temáticos, que serán los puntos de acceso para
las herramientas de reporting. En este sentido, cada departamento tendrá su
propio DataMart, abastecido con la información del DataWarehouse, listo para su
análisis y explotación.
Este enfoque de Inmon suele denominarse como una metodología de trabajo ‘Top-
Down’, ya que se centra primero en una visión global de la compañía, para ir
desmembrándola en pequeños sets de datos departamentales. Así, con esta
arquitectura, todos los DataMartsde la organización están conectados
al DataWarehouse, evitándose la aparición de incongruencias y anomalías al
comparar los datos entre distintos departamentos.

4.2.La estructura del DataWarehouse


En cuanto a la estructura interna del DataWarehouse, para Inmon la prioridad es
que el modelo de datos esté construido en tercera forma normal. Por dar una breve
explicación de lo que esto significa, el proceso de normalización consiste en aplicar
una serie de reglas o normas a la hora de establecer las relaciones entre los
diferentes objetos dentro de la base de datos. Con este proceso de normalización
se consiguen muchos beneficios, como evitar la redundancia de los datos,
mantener su integridad referencial, facilitar el mantenimiento de las tablas y
disminuir el tamaño de la base de datos. Sin embargo, a diferencia de
los DataWarehouse desnormalizados, las consultas exigen el empleo
de queries mucho más complejas, lo que dificulta el análisis directo de la
información y el uso de las herramientas de reporting. De ahí, la necesidad de
construir los DataMarts que, como ya comenté, están basados en modelos
dimensionales de estrella o copo de nieve, diseños fácilmente explotables por
estas herramientas de análisis de datos.
5.tercera forma normal (3NF)

es una forma normal usada en la normalización de bases de datos. La 3NF fue definida
originalmente por E.F. Codd en 1971. La definición de Codd indica que una tabla está en 3NF si
y solo si las tres condiciones siguientes se cumplen:

 La tabla está en la segunda forma normal (2NF)


 Ningún atributo no-primario de la tabla es dependiente transitivamente de una clave
primaria
 Es una relación que no incluye ningún atributo clave

Un atributo no-primario es un atributo que no pertenece a ninguna clave candidata.


Una dependencia transitiva es una dependencia funcional X → Z en la cual Z no es
inmediatamente dependiente de X, pero sí de un tercer conjunto de atributos Y, que a su
vez depende de X. Es decir, X → Z por virtud de X → Y e Y → Z.

Ejemplo[editar]
Un ejemplo de una tabla 2NF que falla en satisfacer los requerimientos de la 3NF es:
La única clave candidata es {Torneo, Año}.
La violación de la 3NF ocurre porque el atributo no primario Fecha de nacimiento del
ganador es dependiente transitivamente de {Torneo, Año} vía el atributo no
primario Ganador. El hecho de que la Fecha de nacimiento del ganador es funcionalmente
dependiente en el Ganador hace la tabla vulnerable a inconsistencias lógicas, pues no hay
nada que impida a la misma persona ser mostrada con diferentes fechas de nacimiento en
diversos registros.
Para expresar los mismos hechos sin violar la 3NF, es necesario dividir la tabla en dos:

Las anomalías de actualización no pueden ocurrir en estas tablas, las cuales están en
3NF.

http://inteligenciadenegociosval.blogspot.com/2014/01/metodologia-de-kimball.html
http://blogs.solidq.com/es/business-analytics/modelado-dimensional-paso-a-paso-15/

https://www.businessintelligence.info/definiciones/que-es-modelo-dimensional.html

https://es.wikipedia.org/wiki/Modelado_dimensional

https://blog.bi-geek.com/arquitectura-el-enfoque-de-ralph-kimball/

https://blog.powerdata.es/el-valor-de-la-gestion-de-datos/qu-son-los-procesos-etl

https://es.wikipedia.org/wiki/Tercera_forma_normal