_ SEP

INSTITUTO TECNOLÓGICO DE ACAPULCO

INGENIERÍA EN SISTEMAS COMPUTACIONALES

MATERIA:
DATA WAREHOUSE

TEMA:
GRANULARIDAD

PROFESOR:
ING. FLORES OLIVEROS RICARDO

ALUMNOS:

GÓMEZ URBANO JESÚS 14320976

HERNÁNDEZ ACEVEDO MOISÉS 14320985
JIMENEZ ROLDAN XAVIER SALVADOR 14321000
LEYVA SALMERÓN RONALD OSVALDO 14321002
LOAEZA JIMENEZ ADRIAN ADAIR 14321003

ACAPULCO, GRO. MAYO DEL 2018.

CONTENIDO

PROBLEMÁTICA .................................................................................................................. 3
OBJETIVO GENERAL ........................................................................................................... 3
OBJETIVOS ESPECÍFICOS ................................................................................................. 3
JUSTIFICACION ................................................................................................................... 3
METODOLOGIA DE RALPH KIMBALL ................................................................................. 5
PARA UN PROYECTO DE DATAWAREHOUSE .................................................................. 5
MARCO TEORICO .............................................................................................................. 35
RESULTADOS .................................................................................................................... 48
CONCLUSION .................................................................................................................... 59
BIBLIOGRAFIA / LINKOGRAFIA ......................................................................................... 60

Página | 2
PROBLEMÁTICA
La granularidad afecta a la cardinalidad, tanto de las dimensiones como de la tabla de
hechos, a mayor granularidad (grano más fino) mayor será el número de registros final
de la tabla de hechos.
Cuando la granularidad es mayor, es frecuente que se desee disponer de subtotales
parciales, es decir, si tenemos una tabla de hechos con las ventas por días, podríamos
interesar disponer de los totales semanales o mensuales, estos datos se pueden
calcular haciendo sumas parciales, pero es frecuente añadir a la tabla de hechos
registros donde se almacenan dichos cálculos para no tener que repetirlos cada vez
que se requieran y mejorar así el rendimiento de la aplicación. En este caso se
dispondrá en la misma tabla de hechos de datos de grano fino y de grano más grueso
aumentando aún más la cardinalidad de la tabla.

OBJETIVO GENERAL
 Definir la descripción de componentes (Granularidad) con la que se debe
trabajar el nivel seleccionado con base en las necesidades que deben suplir
los desarrolladores de Software representada en el nivel de detalle al que se
desea almacenar la información sobre el negocio que se esté analizando.

OBJETIVOS ESPECÍFICOS
 Aprender a identificar la granularidad de las tablas de hechos
 Identificar los niveles de granularidad
 Indicar el grado de detalle asociado a un hecho particular.
 Analizar los factores como la carga del procesador, espacio de
almacenamiento y satisfacer a cabalidad los requerimientos del cliente.

JUSTIFICACION
El aspecto más importante del diseño de un DataWarehouse es la granularidad, que
se refiere al nivel de detalle o sumarización mantenido en el DatawWarehouse, a
mayor detalle menor nivel de granularidad y a menor detalle mayor nivel de
granularidad.
La razón por la cual la granularidad es el principal tema de diseño en el entorno del
DataWarehouse es que afecta al volumen de datos que reside en el DataWarehouse
y al tipo de consultas que pueden ser respondidas.
Muchas veces se necesita eficiencia en el almacenamiento y acceso a los datos y
analizar datos en gran detalle. Cuando una organización tiene grandes cantidades de
datos, tiene sentido considerar dos niveles de granularidad en la porción detallada del
DataWarehouse: datos levemente detallados y datos detallados de archivo. En el nivel
de datos detallados de archivo, se almacena todo el detalle que viene del entorno
operacional, por esta razón se almacenan en cinta.
Página | 3
Por los costos, eficiencia, fácil acceso y habilidad para responder consultas, el nivel
dual de datos es la mejor elección arquitectónica para el nivel detallado del
DataWarehouse para muchos negocios. Solamente cuando un negocio tiene una
cantidad de datos relativamente pequeña en el DataWarehouse puede intentarse un
nivel de datos simp

Página | 4
METODOLOGIA DE RALPH KIMBALL
PARA UN PROYECTO DE DATAWAREHOUSE
La metodología para el desarrollo del proyecto será la establecida por Ralph Kimball,
quien es autoridad en el campo de las bodegas de datos y considerado como uno
de los padres de este concepto. Kimball se ha dedicado al desarrollo de su
metodología para que este concepto sea correctamente aplicado en las
organizaciones, y se asegure la calidad de este tipo de proyectos.

Kimball ha establecido ciertos procesos para llevar al éxito un proyecto de data

warehouse. Para su desarrollo se incluyen varias tareas que pueden ser realizadas
en paralelo o en forma secuencial.

El correcto desarrollo de cada una de las fases planteadas en esta metodología

garantiza la calidad y el correcto proceso de desarrollo.

Planeación y administración del proyecto

Definición del proyecto

Existen varios escenarios posibles en los que surge un proyecto de bodega de datos
para una empresa. Es importante identificar el escenario para determinar el alcance
y definición del proyecto. Los escenarios, originados por una demanda del proyecto
en una empresa son los siguientes:

 Demanda de un sector del negocio: En este escenario, un ejecutivo del negocio

tiene el propósito de obtener mejor información con un mejor acceso para
tomar mejores decisiones.
 Demasiada demanda de información: En este escenario, existen múltiples
ejecutivos del negocio buscando mejor información.
 En busca de demanda. En este escenario usualmente está involucrado el
presidente de una empresa, quien no identifica necesidades de una bodega de
datos para su negocio, pero desea incorporar ese sistema por razones
diferentes a requerimientos o necesidades del negocio

Al identificar el escenario, es posible determinar si existe demanda para el proyecto

y de donde proviene esta demanda. El primer caso es el ideal, pues se tienen
objetivos claros y con un alcance determinado de lo que se quiere del proyecto. El
segundo escenario es riesgoso, pues para implementar una bodega de datos que
soporte varios requerimientos de diferentes áreas de la empresa, se necesita
mucho tiempo, dinero y soporte interno de la organización que perdure a largo plazo.
En el tercer escenario se deben buscar los requerimientos que puede implementar
la solución y basar en ellos el proyecto.

Página | 5
En todos los escenarios es determinante contar con sponsors o patrocinadores
internos del proyecto para lograr el éxito. Sino se cuenta con un patrocinador
interno de la empresa involucrado en la demanda es preferible posponer el
proyecto.

Luego de identificar el escenario es importante conocer si la empresa está lista

para realizar este proyecto.

Determinar la preparación de la empresa para un proyecto de bodega de

datos

De a c u e r d o a Ralph Kimball existen cinco factores que deben existir en una

organización para iniciar un proyecto de bodega de datos.

Patrocinio de la gerencia del negocio: Al contar con este patrocinio se tiene una
visión del impacto que tendrá la bodega de datos en la empresa. Los gerentes
son líderes influyentes dentro de la organización y determinarán el apoyo y soporte
al proyecto de los demás miembros de la organización. Es preferible tener varios
patrocinadores que uno solo, en caso de cambios en la organización o necesidad
un apoyo más fuerte.

 Motivación del negocio: Al implementar una bodega de datos se busca

encontrar un sentido de emergencia por parte de la organización, causado
por una motivación del negocio. Un ejemplo de motivadores son la
competencia y la visión competitiva. Otras organizaciones han encontrado
el motivador en una crisis. Un motivador importante también es un mercado
potencial. Lo importante para un proyecto de bodega de datos es alinearse
con uno de estos motivadores estratégicos del negocio.

 Acompañamiento del departamento de tecnología y de negocio: El éxito de

un proyecto de bodega de datos se produce gracias a un esfuerzo de las
áreas de tecnología y de negocio, compartiendo responsabilidades.

 Presencia de cultura analítica: Es importante que las decisiones

de la organización se basen en hechos, más que en simples intuiciones. Y
que estas decisiones sean determinantes y recompensadas.

 Factibilidad: Es preferible que la infraestructura que soporte la bodega de

datos esté presente y sea robusta. La primera factibilidad debe ser la de
los datos. Si estos se encuentran sucios o no cumplen con estándares, el
proyecto tendrá retrasos respecto al cronograma planeado.

Desarrollo del enfoque preliminar

Página | 6
Luego de haber determinado la preparación de la organización para el proyecto, se
debe centrar el proyecto en su enfoque, y justificarlo para recibir el apoyo y
presupuesto de desarrollo. Para determinar el enfoque, se deben responder
preguntas como: ¿Se busca el enfoque y presupuesto para cubrir el levantamiento
de requerimientos y diseño? ¿O para una primera versión de la bodega? ¿O para
el proyecto completo?

Para definir este enfoque la base debe ser los requerimientos del negocio, no un
cronograma. Para la definición del enfoque es importante seguir los siguientes
parámetros:

 La definición del enfoque es responsabilidad del departamento de

tecnología y de negocio: El enfoque usualmente se establece para desarrollar
requerimientos específicos del negocio, en un tiempo determinado.
 El enfoque inicial del proyecto debe ser factible y manejable: Es preferible
empezar “pequeño”. Luego continuar el proceso de forma iterativa.
Lanzando pequeños y rápidos desarrollos del proyecto.
 Enfoque inicial en un solo requerimiento del negocio soportado por una
sola fuente de datos.
 Limitar el número de usuarios que tendrán acceso a la bodega de datos
inicialmente.
 Establecer criterios de éxito del proyecto mientras se define el enfoque: Se
refiere a entender lo que la gerencia espera del proyecto.

Una vez el área de tecnología y negocios han acordado un enfoque, este se debe
documentar.

Desarrollar la justificación del negocio

Luego de haber definido el enfoque, la justificación debe ser establecida. Esto

significa que se identifican anticipadamente los costos y beneficios asociados al
proyecto. Una forma de hacer esto es con el factor retorno de la inversión (ROI),
que consiste en comparar el retorno financiero esperado (beneficios del negocio)
contra la inversión esperada (costos).

Se deben considerar las siguientes inversiones y costos:

 Compras de licencias de software y hardware.

 Costos de mantenimiento: muchos productos de hardware y software
requieren mantenimiento.
 Recursos internos de desarrollo.
 Recursos externos requeridos.
 Capacitación para desarrolladores y usuarios.
 Soporte a usuarios

Página | 7
Los proyectos de bodegas de datos típicamente tienen un impacto en el incremento
de ingresos y ganancias, más que en reducción de costos.

 Incremento de ingresos por nuevas ventas a nuevos y antiguos clientes.

 Incremento de ganancias por aumento de respuestas a la publicidad.
 Incremento de niveles de servicio al cliente.
 Descubrimiento de nuevas oportunidades.

Planeación del proyecto

El proyecto de bodega de datos debe tener un nombre. Luego, se identifican roles

que pueden ser cubiertos por uno o varios integrantes del equipo y cada miembro del
equipo también puede desempeñar varios roles, dependiendo de los
requerimientos y del tamaño del proyecto. Los siguientes roles se identifican para
el proyecto:
 Patrocinadores de negocio.
 Gerente del proyecto: Responsable de la gerencia de tareas y
actividades cotidianas.
 Líder de negocios del proyecto: Con el gerente del proyecto monitorea
el proyecto y lo comunica a la organización. Tiene un alto entendimiento de
los requerimientos del negocio.
 Analista del sistema de negocios: Lidera las actividades de definición
de requerimientos.
 Modelador de datos: responsable del análisis de datos y el modelo
dimensional.
 Administrador de bases de datos de la bodega (DBA): Responsable
de determinar agregaciones, particiones y soporte a la base de datos.
 Diseñador de proceso ETL: Responsable del diseño de la
extracción, transformación y carga de la bodega.
 Desarrolladores de aplicación al usuario.
 Educador de la bodega de datos.
Desarrollo del plan del proyecto
El objetivo de la planeación es proveer el detalle suficiente para hacer seguimiento al
progreso del proyecto. Se identifican actividades, recursos y tiempos para el
desarrollo. También permite monitorear los procesos y tener un plan de riesgos.
Administración del proyecto
Se consideran las reuniones de equipo, monitoreo del estatus, el enfoque y
estrategias de comunicación.

Página | 8
Análisis de requerimientos
Acercamiento a la definición de requerimientos

Para entender mejor los requerimientos se debe empezar por hablar con los usuarios
de lnegocio. No se debe preguntar a estos usuarios, qué datos quieren que aparezcan
en el datamart, sino hablar con ellos sobre sus trabajos, objetivos y retos e intentar
conocer cómo toman decisiones, actualmente y en el futuro.
Se debe considerar lo que requiere el negocio comparando estos requerimientos con
los datos disponibles en las bases de datos que servirán como fuente, para lograr el
soporte de estos requerimientos.

Preparación de la entrevista

Se deben determinar roles y responsabilidades en el equipo entrevistador. Es

preferible que el mismo equipo conduzca las entrevistas a usuarios del negocio y al
equipo de tecnología de la empresa.
Los roles que se deben manejar, comprenden a un líder, encargado de dirigir el
cuestionario, debe tener habilidades en el conocimiento del negocio y
comunicaciones. También debe existir un “escribano” encargado de tomar notas
durante las entrevistas. Se debe tomar el mayor detalle posible del contenido. Al
finalizar las entrevistas, esta persona debe hacer preguntas para aclarar dudas y
obtener una retroalimentación de los entrevistados.

Investigación previa a entrevistas.

Antes de iniciar el proceso de levantamiento de requerimientos, se deben analizar los
reportes anuales de la compañía, para determinar las decisiones y hechos
estratégicos. También es útil obtener planes de negocios de la compañía. También
se debe analizar la competencia de la compañía y sus principales fortalezas y
debilidades. Si ha existido un intento anterior de desarrollar una bodega de datos de
la compañía, este también se debe analizar.

Selección de los entrevistados

Se deben seleccionar personas representativas de cada área de la organización. Es
importante observar el organigrama de la compañía para determinar los candidatos
a entrevista. Los principales entrevistados deben ser los administradores ejecutivos
del negocio, para comprender la estrategia en un alto nivel de la empresa.
Luego es importante entrevistarse con los analistas del negocio de cada área quienes
conocen el manejo de información que se lleva a cabo.

Página | 20
Desarrollo del cuestionario
El líder de la entrevista debe desarrollar el cuestionario antes de iniciar la entrevista.
Se deben desarrollar varios cuestionarios que serán aplicados dependiendo del rol de
los entrevistados dentro de la empresa. El cuestionario debe ser de una sola página,
para evitar exceso de tiempo de entrevistas.

Modelamiento dimensional
Modelo entidad relación
El modelo entidad relación (ER) es una técnica poderosa para diseñar
lógicamente sistemas para el procesamiento de transacciones OLTP (procesamiento
transaccional en línea). Siempre va encaminado a la eliminación de la redundancia,
lo que permite que la manipulación sobre la base de datos tenga que hacerse en un
solo lugar y sea mucho más rápido ya que en el momento en que la transacción
requiera insertar, adicionar, borrar o modificar un dato es necesario que lo haga en un
solo lugar y no en múltiples. Esto contribuye también al almacenamiento de grandes
cantidades de datos dentro de las bases de datos relacionales, a través del
proceso de normalización. Por eso es perfecto para la inserción y actualización de
la información.
Este es un modelo excelente para registrar transacciones y administración de
tareas operativas. Sin embargo, para el modelamiento de una bodega de datos
presenta varios problemas. Los usuarios finales no entienden ni recuerdan un
diagrama entidad relación. Nos es posible que los usuarios finales naveguen sobre el
modelo. El uso del modelo entidad relación va en contra del objetivo principal de una
bodega de datos, de proporcionar datos de forma intuitiva y con un buen desempeño
y tiempos de respuesta.

Modelo Dimensional
El modelo dimensional es una técnica de diseño lógico que busca presentar los datos
de una forma intuitiva y que proporcione acceso de alto desempeño. Cada modelo
dimensional se compone de una tabla con múltiples llaves foráneas, llamada tabla de
hechos (fact table), y un conjunto de tablas más pequeñas, llamadas tablas de
dimensión.
Los atributos de las tablas de dimensión son las fuentes de las restricciones de
búsqueda necesarias para consultar una bodega de datos. Son utilizadas como título
de atributo de las filas resultantes de queries de SQL.
Existen dos modelos dimensionales que predominan en las soluciones de bodegas
de datos: el modelo estrella y el modelo copo de nieve. En el modelo estrella, como
se ve en la figura 5 se tiene una tabla de hechos y en ella llaves foráneas a cada una
Página | 21
de las tablas de dimensión que tiene el modelo. Es decir, cada tabla dimensional
está directamente relacionada a la tabla de hechos

Modelo estrella
Una dimensión es modelada de forma copo de nieve cuando los campos de baja
cardinalidad de la dimensión han sido removidos a tablas separadas y unidas a la
tabla original con llaves foráneas . En este modelo la tabla de hechos no tendrá llaves
foráneas a todas las demás tablas como en el caso de la estrella. Las nuevas tablas
no estarán conectadas con la tabla de hechos sino con las dimensionales
establecidas.

Modelo copo de nieve

Generalmente el copo de nieve no es recomendado en ambientes de bodegas de
datos. Este modelo será más complejo para los usuarios y la navegación por el
modelo será más lenta.

Diseño de dimensiones y hechos

En el desarrollo de una bodega o un datamart comúnmente es necesario unir
datamarts. Esto se logra creando una arquitectura de bus de datamarts. Como se

Página | 22
utilizarán las mismas tablas de dimensiones, es importante que las tablas de
dimensiones y hechos cumplan con las mismas especificaciones, como su
granularidad. Estas dimensiones son llamadas dimensiones conformes (conformed
dimensions). Se caracterizan por cumplir estas condiciones.

1. Una tabla de dimensión puede ser usada con cualquier tabla de hechos de la
misma base de datos
2. Las interfaces de usuario y contenido de datos son consistentes para
cualquier uso de la dimensión.
3. Hay una interpretación consistente de atributos, por lo tanto, se obtiene la
misma interpretación de la tabla en cualquier datamart.

La granularidad es un factor que se debe tener en cuenta para el diseño de las

tablas. Una bodega de datos debe mantener sus dimensiones basadas en datos con
la mayor granularidad posible. De esta forma se facilita la expansibilidad de los
datamarts para contener nuevos atributos, ya sea en las tablas de dimensiones o
en la de hechos. Además, se permite de esta manera realizar técnicas de minería
sobre la bodega, las cuales comúnmente requieren una alta granularidad.

Modelo de cubo multidimensional

Al diseñar las tablas de hechos y dimensiones, la idea principal es permitir que

cada dato del negocio sea representado como un cubo. Donde las celdas del cubo
contienen valores medidos y los bordes del cubo definen las dimensiones de
los datos. Comúnmente al modelar datos de negocios se obtienen entre 4 y 15
dimensiones. En el ejemplo de la figura se modela un cubo con las dimensiones
Producto, Tiempo y Ciudad. A la derecha de la figura aparece el modelo dimensional
que representa al cubo, con las tres dimensiones unidas a la tabla de hechos.

Página | 23
Hechos

Los hechos son medidas de las variables que se consideran. Un hecho puede ser
el valor de una factura con sus respectivas relaciones: la factura es generada a un
cliente, correspondiente a un producto, creada en una sucursal.

Al seleccionar los hechos para el diagrama dimensional, se debe sospechar

que cualquier valor numérico, especialmente si es de tipo flotante, es probablemente
un hecho. Es de especial utilidad que cada hecho sea aditivo, para los análisis propios
de la bodega.

Dimensiones
Los atributos de tipo texto que describen cosas son organizados en dimensiones.
Es necesario establecer un criterio puramente de diseño y basado en los
requerimientos del negocio para establecer los atributos que se incluyen como
dimensiones y los que se pueden descartar al realizar la bodega de datos.
Los atributos dimensionales, servirán como fuente para las restricciones y
encabezados de filas en los reportes. Todos los atributos dimensionales son
igualmente candidatos a ser encabezados de filas en los reportes.
Al agregar restricciones a una búsqueda o reporte, se está haciendo un drilling down,
es decir se está estableciendo una nueva restricción en una búsqueda para
obtener un mayor nivel de detalle. Un drill down eficiente mezcla atributos de las
diferentes dimensiones, para realizar reportes realmente robustos.

Llaves subrogadas
Todas las llaves de las tablas de la bodega de datos deben ser llaves subrogadas, es
decir no deben significar nada respecto a las características de su contenido ni a su
fuente en los sistemas fuente. No se deben utilizar las llaves originales de un sistema
fuente del cual fueron extraídas. Estas llaves subrogadas se manejan como enteros.

Método de diseño de una tabla de hechos

Para el diseño de la tabla de hechos, de acuerdo a la metodología de Ralph Kimball
se deben seguir los siguientes pasos, de cada paso depende el siguiente. Se deben
tomar decisiones respecto a:

1. El datamart.
2. La granularidad de la tabla de hechos.
Página | 24
3. Las dimensiones.
4. Los hechos.

1. Selección del datamart.

Para un correcto desarrollo de una bodega, es preferible seleccionar e implementar
primero los datamarts que dependan de una sola fuente y luego continuar con los que
deben extraer datos de múltiples fuentes. En el caso más simple, seleccionar el
datamart es lo mismo que seleccionar la fuente legacy de datos. En casos más
complejos, se puede definir un datamart que deba incluir múltiples fuentes legacy.

2. Declaración de granularidad de la tabla de hechos.

Es necesario definir claramente lo que es un registro de la tabla de hechos en el
diseño dimensional propuesto. La granularidad es la respuesta a la pregunta ¿Qué es
un registro de la tabla de hechos?

La granularidad se refiere al nivel de detalle existente en las unidades de los datos de

la bodega. Entre más detalle halla, menor será el nivel de la granularidad. Entre menos
detalle halla, mayor será la granularidad. Es un factor determinante en el desarrollo
de la bodega, debido a que de ella depende el volumen de datos que será almacenado
en la bodega y el tipo de queries que pueden ser realizados.

Ejemplo de granularidad en una empresa de telefonía.

Generalmente la granularidad de la tabla de hechos es seleccionada como la más

baja o granular posible. Existen varias ventajas para seleccionar este tipo de
granularidad como una transacción individual o una línea de documento. De esta
forma será mas fácil responder a nuevas consultas y agregar nuevos datos.

Página | 25
3. Selección de dimensiones.
Generalmente la granularidad determina unas dimensiones mínimas e iniciales. Al
agregar nuevas dimensiones los atributos de estas deben cumplir con la misma
granularidad que se ha definido. La granularidad de un dimensión no puede ser
menor que la granularidad de la tabla de hechos.

4. Selección de los hechos.

La selección de granularidad de la tabla de hechos también permite seleccionar
los hechos. En el caso de tabla de hechos de transacciones habrá un solo hecho,
el monto de la transacción. Si el caso es una tabla de hechos de snapshot puede
contener diversos resúmenes de las actividades realizadas en la toma del
snapshot. Como cantidad vendida, valor, costo. Los hechos siempre deben ser
específicos a la granularidad de la tabla de hechos.

Diseño técnico de la arquitectura

En los sistemas de información la definición de una arquitectura permite hacer un
desarrollo más confiable y eficiente. Con la definición de la arquitectura se mejora
la comunicación entre las diferentes áreas del proyecto, el planeamiento del
proyecto, la flexibilidad y el mantenimiento del mismo.

Aspectos de arquitectura
Para hacer el diseño de la arquitectura se debe comenzar analizando los sistemas
legacy actuales, estos deben ser consistentes y manejar de forma correcta sus
transacciones, pues en la metodología del desarrollo del DWH (Data warehouse)
se toma como hecho que estos sistemas son confiables.
Para hacer el diseño de la arquitectura se debe comenzar analizando los sistemas
legacy actuales, estos deben ser consistentes y manejar de forma correcta sus
transacciones, pues en la metodología del desarrollo del DWH se toma como hecho
que estos sistemas son confiables.

Página | 26
 NIVEL DE DETALLE Datos (el qué) Back Room(el Front Room (el Infraestructura (el
como) como) donde)

Auditoria para los Que información se Como se hará el ¿Cuales son los ¿Que niveles
requerimientos del necesita para tomar proceso ETL y como principales retos que de DWH y
negocio mejores decisiones del se tendrán los datos enfrenta el negocio? sistemas se
negocio?, disponibles para los requieren para
usuarios? ¿Como se quieren tener éxito?
¿Cómo se conectarán analizar los datos?
los componentes de ¿Cómo se hace ¿Cuáles
datos en la actualmente? existen
arquitectura de bus? actualmente?

Modelos y Modelo dimensional: ¿Que características ¿Que requerirán los ¿Cual es el origen y
documentos de especificas se usuarios para cargar destino de los datos
Arquitectura ¿Cuales son las necesitaran para la información de
principales entidades tener los datos en una forma útil? ¿Se tiene suficiente
que componen esta una forma útil en los capacidades de
información y como se lugares apropiados? ¿Qué clases de procesamiento y
relacionan? análisis y reportes se almacenamiento?
¿Cuáles son deben proveer y
¿Cómo se deben los principales cuales son las
estructurar estas almacenes de prioridades?
entidades? datos y donde
deben estar
localizados?

Especificaciones y Modelos lógicos y ¿Que estándares y ¿Cuales son las ¿Como se interactúa
modelos físicos: con estas
productos proveen especificaciones características?,
¿Cuales son los las características de reportes
elementos requeridas?, incluyendo filas, ¿Qué utilidades
individuales, sus ¿Cómo se columnas, existen en el sistema,
derivaciones y reglas relacionaran?, secciones, API,s etc?
para la derivación? encabezados,
¿Cuáles son los etc..?,
¿Cuáles son los estándares para
recursos y como se desarrollo, ¿Quién las
mapear a los administración necesita, que tan
destinos? de codigo y a menudo?
nombres?

Implementación Crear bases de datos, Escritura de Implementación del Instalación y pruebas

índices, Back up, extracciones y ambiente de reporte de nuevos
documentación?. cargas, y análisis, componentes de la
automatización de infraestructura.
procesos, Construcción del
documentación. conjunto de reportes Conexión de las
inicial. fuentes a los destinos
y los clientes.

Tabla 1. Bases de la estructura de la arquitectura de Dataarehouse

En la tabla 1 se muestran las bases para la estructura de la arquitectura de un

DWH. Entre l a s áreas principales se pueden destacar los datos, el área técnica

Página | 27
y la infraestructura. Estas áreas de la arquitectura son interceptadas por filas que
nos indican el detalle del incremento.

Definición: Columnas
Datos: El contenido del DWH son datos. Estos se refieren a todo el contenido físico
del este(DWH) que mas adelante se la hará un tratamiento para permitir ver análisis
multidimensionales y reportes útiles que apoyen la toma de decisiones. Los
Datos guardan toda la información del ambiente del DWH y de las fuentes que surten
a este.
Técnica: Esta área corresponde a los procesos y a las herramientas que se aplicaran
sobre los datos. Esta área se encarga a de responder a la preguntas “Como”.
Por ejemplo ¿Cómo vamos a extraer los datos de la fuentes?, ¿Cómo los podemos
organizar de forma que podamos hacer análisis conforme a los requerimientos del
negocio?, entre otras. Esto se enfoca principalmente a las herramientas, al
desarrollo del DWH y al mantenimiento del mismo. Para garantizar un mejor
funcionamiento del área técnica estas se divide en:
 El Back Room : Es el área del DWH responsable de extraer y preparar los
datos.
 El Front Room: Es el área del DWH responsable de mostrarle a los usuarios
los resultados con los datos analizados y examinados, listo para que se puedan
ser utilizados.
Infraestructura: Corresponden la las plataformas sobre las que se ejecutan los
servidores de base de datos, los servidores de aplicaciones y donde se ejecutan
los procesos. La infraestructura es la planta física del DWH, se refiere principalmente
al hardware utilizado para el desarrollo del proyecto.

Definición de los niveles de detalle (las filas).

Se comenzará desde los niveles mas altos de detalle. Parte de esa arquitectura trata
de hacer modelos y documentos de diferentes niveles de detalle, algunos cercanos y
otro no tan cercanos a la realidad.
Los mayores niveles de detalle de la arquitectura se usan para diseñar una estructura
y obtener un mejor entendimiento de los niveles de detalle mas bajos. Los modelos
detallados ayudan a tomar rápidamente las especificaciones que se deben tener
en cuenta durante el diseño y que por ningún motivo se pueden pasar por alto, pues
de esta forma no se tendría un entendimiento total del negocio.
Nivel de requerimientos del negocio: Este nivel no trata de ninguna implementación
técnica del DWH, el interés del arquitecto del proyecto se centra en entender el
comportamiento de los negocios, los procesos de la empresa y las limitaciones que
podrían ir en contra del desarrollo del DWH.

Página | 28
Nivel de modelos de arquitectura: Este es el primer donde se piensa en la forma de
responder a los requerimientos.

Un modelo de arquitectura, propone los principales componentes de una arquitectura

que se deben implantar para consecución de los requerimientos. Todas las
tecnologías de arquitectura, deben ser justificadas y deben garantizar que funcionan
juntas en un sistema. Se debe definir si los componentes técnicos se comunican unos
con otros, si las suposiciones administrativas para usar la tecnología son razonables
y si la organización tiene recursos para soportar esta tecnología.
Nivel de detalle del modelo: Hace referencia a las especificaciones funcionales de
cada componente de la arquitectura, esto debe incluir suficiente información que sirva
como guía al equipo de desarrolladores para tener una implementación mas confiable
y con menos errores. Esto también sirve en el caso que se quiera establecer un
contrato legal, pues lo establecido en el la especificación es lo mismo que se va
implementar y se puede evitar que el cliente exija mas funcionalidades cuando nunca
fueron determinadas formalmente.El modelo dimensional y modelo físico de una fact-
table corresponden la los modelo de detalle para el área de datos.
Nivel de implementación: La implementación es realizada a partir de los detalles del
modelo, pues ahí se tiene considerado la arquitectura y detalles para llevar acabo
el desarrollo. El desarrollo del proyecto debe estar documentado.

Procesos de extracción, transformación y carga

Este proceso comprende varios aspectos determinantes para la bodega de datos. Por
lo tanto se debe seguir un plan para su correcto desarrollo. Se establecen varios pasos
que conducen al desarrollo del proceso y se describen a continuación.

Paso 1. Plan de alto nivel

El proceso de diseño se inicia con un esquema simple de los componentes del plan
que son conocidos: Las fuentes y los destinos de los datos. Se identifica de donde
provienen los datos y las características y problemas con dichas fuentes. Con este
esquema es posible comunicar la complejidad del proyecto a la gerencia y miembros
del equipo de desarrollo del proyecto.

Las aplicaciones de ETL realizan tres pasos: extracción, transformación y carga a

la bodega de datos. Estos pasos se deben ver en un esquema de alto nivel: Tomar
los datos de las fuentes, transformarlos y cargarlos en los destinos.

Página | 29
Paso 2. Herramientas ETL
Las extracciones típicamente se escriben en el lenguaje de la fuente de los
datos. Existen herramientas que realizan todo el proceso de extracción,
transformación y carga que buscan minimizar el tiempo requerido para estas tareas.
Estas herramientas implican un costo por licencias y posibles incompatibilidades o
dificultades con transformaciones complejas que fuesen requeridas para el proceso.
Ya se haga el proceso con código desarrollado, o herramientas existentes, es
determinante realizar prácticas que mejoren el rendimiento del proceso, como
ordenar los datos o cargarlos de forma rápida para cargas masivas en las bases de
datos.

Paso 3. Plan detallado

El plan se inicia seleccionando la tablas en las que se va a trabajar, en cual orden y
secuenciar las transformaciones para cada conjunto de datos. Se debe graficar
un diagrama con estas estructuras.
Todas las tablas de dimensión deben ser cargadas antes que las tablas de hechos.
Se debe iniciar el desarrollo de la aplicación ETL con la dimensión más simple y
continuar con las demás hasta llegar la tabla de hechos.

Paso 4. Poblar una tabla de dimensión simple

La principal razón para iniciar el proceso con una dimensión estática y simple es la
facilidad para poblar esta tabla. A continuación se presenta información para realizar
el proceso completo de ETL relevante a cualquier tabla destino (dimensiones y
hechos).
• Extracción de una dimensión
Se deben entender las características de la fuente de datos. Si la fuente es
relevante para la dimensión destino, como se actualiza esta fuente, si hay alguna hora
en el día en la cual no se deba acceder a esta fuente, son preguntas que se deben
resolver en esta etapa.
También se deben generar reportes “de extracción”, que permitan extraer únicamente
los campos o datos requeridos de cada fuente.
Existen dos fuentes principales de datos: archivos y bases de datos. Si la fuente se
encuentra en una base de datos, se crea un solo proceso que haga fluir los datos
desde la fuente a la sección de transformación y carga. Si la fuente es un archivo, se
requieren varios pasos en el proceso: extracción al archivo, ubicación del archivo en

Página | 30
el servidor del proceso, transformar los datos del archivo y cargar el archivo en la base
de datos utilizada para transformar y cargar datos.

• Transformación de una dimensión

Existen transformaciones comunes y sencillas, como el cambio de un tipo de dato a
otro, o cambiar letras minúsculas por mayúsculas, otras más complejas se indican a
continuación.
- Asignación de llaves substitutas (surrogate en inglés)
Las llaves substitutas son las llaves primarias de las tablas del modelo dimensional,
que son diferentes y no deben tener ninguna relación con las llaves primarias de las
tablas fuentes ni de los datos mismos. Típicamente se utilizan enteros para estas
llaves.
• Carga
Para mejorar el rendimiento, la primera carga a la bodega se debe hacer con las
características de población masiva de datos del motor de base de datos del
modelo dimensional. Los principales motores de bases de datos tienen esta
característica y su uso depende del producto utilizado.

Paso 5. Implementación de la lógica del cambio de una dimensión

Al cambiar los datos de una dimensión, ya sean nuevos o actualizaciones a los datos
previos, es preferible construir la extracción de tal forma, que se extraigan únicamente
los datos que han cambiado.
Al determinar los cambios, se debe contar con reglas del negocio que determinen
como manejar estos cambios en los atributos. Si se determina que la modificación es
legítima y es posible actualizar el dato, se utiliza la técnica de una dimensión
cambiante.
El primer paso para preparar la dimensión consiste en determinar si ya existe un
registro antiguo del dato. Al encontrar una modificación se aplica alguno de los
siguientes tipos de respuesta al cambio.
 Tipo 1: Sobrescribir.
Se toma el nuevo dato de la fuente y se sobrescribe la tabla de la dimensión
con el nuevo contenido.
 Tipo 2: Crear un nuevo registro de la dimensión.
Se crea un nuevo registro de la dimensión con una nueva llave subrogada.
 Tipo 3: Bajar el antiguo valor.

Página | 31
 Se crea un nuevo campo en la dimensión que contenga el antiguo valor del
dato modificado y se actualiza la dimensión con el nuevo contenido.

Paso 6. Poblar las dimensiones restantes

Para poblar el resto de dimensiones se sigue el proceso del paso 4, y se cargan ya
sea con el uso de una herramienta de carga existente o con el desarrollo de una que
soporte conexiones ODBC o JDBC.

Paso 7. Carga histórica de hechos

En el proceso de ETL debe existir un paso para reemplazar las llaves primarias de las
fuentes por las llaves subrogadas que se han asignado a cada dimensión, y que deben
ir como llaves foráneas en la tabla de hechos.
Para mantener una integridad referencial en la bodega, - que significa que por cada
llave foránea en la tabla de hechos exista un registro en la dimensión correspondiente
– se realizan dos búsquedas de llaves subrogadas en el proceso de extracción. Una
ocurre cuando se utiliza la técnica 2 del paso 5, y se ha creado un nuevo registro
de una dimensión que contiene una nueva llave subrogada y un campo modificado
con el resto del contenido original. La segunda búsqueda ocurre cuando se están
procesando los registros de la tabla de hechos. En este momento se debe
buscar en todas las dimensiones los registros que coincidan con el dato que se está
buscando relacionar con la tabla de hechos, y una vez encontrado el registro de la
dimensión, agregar su llave subrogada a la llave foránea de la tabla de hechos.
Este proceso funciona bien para bodegas de datos que no manejan grandes
cantidades de registros, pues al ser grande el tamaño de datos es preferible mantener
una tabla de búsqueda que registre la llave primaria en la fuente y la llave
subrogada en la dimensión. D esta manera se mejora el rendimiento al poblar la
tabla de hechos.
Una vez se cuenta con todas las llaves foráneas de la tabla de hechos, esta tabla se
empieza a cargar.

Paso 8. ETL de una tabla de hechos incremental

Al realizar cargas semanales o periódicas a la bodega desde las fuentes, es decir
al actualizar la bodega, se deben extraer y procesar únicamente las transacciones
que han ocurrido luego de la última carga.
Para seleccionar únicamente estas nuevas transacciones se pueden usar los logs de
las bases de datos, y de esta forma identificar los datos que han cambiado en el
período analizado. El log captura cada cambio que haya sido realizado a un registro.
Página | 32
También es posible crear losgs en las bases de datos fuentes que registren
únicamente los cambios que son importantes para la bodega, utilizando triggers.
Paso 9. Operación y automatización de la bodega de datos

Idealmente el proceso ETL de una bodega de datos se ejecuta de manera automática

y no atendida. Las operaciones típicas en la bodega son que se deben tener en cuenta
en este paso son las siguientes:
 Definición de tarea – Flujos y dependencias
 Horarios de tareas – basadas en tiempos y hechos
 Monitoreo
 Logging
 Manejo de excepciones
 Manejo de errores
 Notificaciones

Mejoramiento de datos.
Para garantizar el uso de los mejores datos posibles para la bodega, se deben tener
en cuenta los siguientes pasos:
 Identificar la fuente de datos con la mejor calidad: Es posible que se encuentren
varias fuentes con los mismos datos, pero en algunas se tenga mejor calidad
de los mismos.
 Identificar variaciones en palabras: Como errores de ortografía y mayúsculas y
minúsculas.
 Discutir problemas de datos con el equipo.
 Arreglar los problemas de datos en las fuentes cuando sea posible, en vez de
hacerlo en el proceso ETL o directamente a la bodega.
 - No arreglar todos los problemas. Si existen muchos problemas en las
fuentes, arreglarlos en el proceso ETL irá en contra del rendimiento, estos
problemas deben ser responsabilidad de los sistemas fuentes.
 Realizar tareas de limpieza sobre los datos

Mantenimiento y crecimiento de un d ata warehouse

Administración del entorno de data warehouse
Cuando una empresa adquiere sus sistemas de información el cambio que tendrán
estos sistemas es muy poco, sin embargo cuando se desarrolla un proyecto de DWH
se debe pensar en el mantenimiento posterior a la implementación, pues estas
aplicaciones tienen gran tendencia a crecer a medida que crece la información de la
organización.
Página | 33
La inversión en el mantenimiento del DWH es bastante importante, sin embargo estas
aplicaciones retornan la inversión que se les hace.

Diagnóstico de resultados incorrectos

Cuando se tienen problemas en el DWH y no se tienen los resultados esperados, se
debe revisar alguno de los pasos anteriores en el ciclo de vida. También se tiene una
serie de preguntas que en el caso de no ser positivas, hay mas razones para revisar
los pasos anteriores.

 ¿El proyecto tiene el apoyo de los altos ejecutivos de la organización?

 ¿El equipo de desarrollo del proyecto entendió correctamente los
requerimientos del usuario?
 ¿Los usuarios finales entienden el modelo dimensional o tienen que recurrir a
las complicada tablas del datamart directamente?
 ¿Para la escogencia de las herramientas análisis de datos, los usuarios finales
fueron considerados en el proceso?
 ¿Los datos utilizados para alimentar el datamsart son correctos

Página | 34
MARCO TEORICO

El Data Warehouse es un conjunto de procesos y acciones que involucra un

almacenamiento de datos no volátil, orientado a un tema, integrado e histórico para el
soporte al proceso de toma de decisiones de la gerencia.
Es una técnica para consolidar y administrar datos de diversas fuentes con el
propósito de responder preguntas de negocios y tomar decisiones (Ver figura 1). Está
constituido por la correcta organización e interrelación de los desarrollos tecnológicos
consistentes en: consolidar datos desde una variedad de fuentes; manejar grandes
volúmenes de datos de una forma que no era posible, acceder a los datos de una
forma más directa, en "el lenguaje del negocio", y analizarlos para obtener
relaciones complejas entre los mismos.

Necesidad de información que soporte decisiones del negocio

Un sistema Data warehouse define un nuevo concepto para el almacenamiento de
datos, integra la información generada en todos los ámbitos de una actividad
de negocio (ventas, producción, finanzas, Marketing, etc.) que proviene de
diferentes fuentes, formatos y tipos en un único depósito y permite un acceso
y explotación de la información contenida en las bases de datos, facilitando un
amplio abanico de posibilidades de análisis multivariables que permitirán la
toma de decisiones estratégicas.
Página | 35
Componentes de un data warehouse
El Data Warehouse tiene varios componentes dentro de su arquitectura.
Está conformado por:

1) El repositorio de datos o bodega de datos

2) Los procesos de:
 Extracción
 Transformación
 Carga
 Explotación

Bodega de datos y datamarts

En 1992, Inmon define la bodega de datos como: " una colección de datos orientados
a temas, integrados, no-volátiles y variante en el tiempo, organizados para soportar
decisiones empresariales"2.
En 1993, Susan Osterfeldt publica una definición que sin duda es la clave de bodega
de datos: "Yo considero la bodega de datos como algo que provee dos beneficios
empresariales reales: Integración y Acceso de datos. La bodega de datos elimina una
gran cantidad de datos inútiles y no deseados, como acierta también el procesamiento
desde el ambiente operacional clásico".
El datamart se ajusta a la definición de una bodega de datos, con la diferencia que su
enfoque es servir a un área específica del negocio. Los procesos y fuentes de datos
necesarios para construir un datamart son iguales que en el caso de la bodega, pero
la información almacenada en el datamart proporcionará información específica,
como información de ventas, o de producción. De todas formas no se puede
considerar a un datamart como una “pequeña bodega”, pues un datamart puede
ser más complejo y contener mayor volumen de datos que toda una bodega,
dependiendo del negocio y los requerimientos de cada caso.

Página | 36
Datamart, proporciona información a un área específica de la organización

Es así que la bodega de datos y el datamart son un repositorio centralizado que

contiene datos de una o diversas fuentes y que está específicamente diseñado
para permitir consultas y análisis detallado de los datos. En el caso del datamart, este
análisis tiene un enfoque determinado a áreas específicas del negocio.

Características de la bodega de datos

La bodega de datos se caracteriza por ser:
Temático: La bodega de datos está orientada a los principales temas o entidades de
la organización lo cual está en contraste con la mayoría de los sistemas de hoy en día
cuya orientación se basa en los procesos o funciones.
De acuerdo con esta característica, la bodega de datos para una empresa de ventas
se enfocaría en proveedores, clientes, productos, mientras que un subsistema típico
lo haría en proceso de compras, de ventas, de inventario.
Integrada: Los datos almacenados deben integrarse en una estructura consistente.
Esto se refleja en consistencia de nomenclaturas, de variables y medidas, de
estructuras y códigos, de atributos de datos afines, etc.
Histórico: El tiempo es parte implícita de la información contenida en una bodega de
datos. A diferencia de los sistemas transaccionales, que mantienen los
datos actualizados a un instante determinado en el tiempo, una bodega de
datos puede mantener información de más de un instante. La bodega se carga
con los distintos valores que toma una variable en el tiempo y de esta manera los
datos pueden ser analizados y comparados, facilitando las labores gerenciales.
No volátil: La información de la bodega de datos existe para ser leída y no modificada,
por lo tanto, se carga una sola vez y permanece igual en adelante. De esta manera la
actualización de la bodega de datos es la incorporación de los últimos valores
que tomaron las distintas variables, sin ningún tipo de acción sobre lo que ya existía.
Eso esta en contraste con la informacion de un sistema transaccional que esta sujeta
a permanentes insercciones, actualizaciones, reemplazos o borrado

Proceso de extraccion, transformacion y carga de los datos

Para obtener la bodega de datos se desarrollan en forma secuencia la extraccion de
los datos, su transformacion y finalmente su carga en la bodega. El proceso de
extraccion consiste en la obtencion de la informacion desde las distintas fuentes
(base de datos y archivos operaciones) tanto internas como externas mediante
herramientas de gestion de datos .
Página | 37
 Procesos de extracción, transformación o elaboración y carga.

A continuación es necesario transformar los datos en los requeridos para el depósito.

El proceso consiste en filtrado, limpieza, depuración, homogeneización e integración
de la información. Esto debe hacerse, ya que las bases de datos operacionales,
diseñadas para el soporte de varias aplicaciones de producción, frecuentemente
difieren en el formato, entonces, pueden tenerse los mismos elementos de datos, pero
nombres y formatos y codificaciones incoherentes. Todas estas inconsistencias
deben resolverse antes de realizar el último paso de este proceso que corresponde
a la carga de los datos en la bodega.

Explotación
Es importante recordar que la Bodega de Datos no es un fin en sí misma, sino que es
un medio para solucionar una necesidad: el análisis de información y la toma de
decisiones a través de los datos de la empresa, objetivo que se logra con el proceso
de explotación de la bodega de datos.
En esta etapa es donde se desarrolla la inteligencia del Negocio y por lo tanto es un
componente esencial del data warehouse, ya que es el punto de contacto directo con
el usuario final, quien es el encargado de tomar decisiones o acciones que redundan
en beneficio de la compañía y en el ROI (Retorno de la Inversión) del Data
Warehouse.
Las herramientas utilizadas para el desarrollo de inteligencia del negocio pueden
incluir software de consultas, generadores de reportes, procesamiento analítico
en línea, herramientas de minería de datos, etc., dependiendo de los tipos de
usuarios y sus requerimientos particulares. Sin embargo, se hace necesaria la
integración de varias herramientas puesto que una sola no satisface todos los
requerimientos.
Los niveles de aplicaciones típicas en esta etapa son: Consultas e Informes,
Olap, minería de datos, Sistemas de Información Ejecutiva, y Visualización
geográfica.
Página | 38
Análisis OLAP
OLAP, (On-Line Analytical Processing). El Procesamiento Analítico en Línea es
la técnica que permite ver y manipular los datos por dimensiones, proveyendo
a los gerentes y analistas fácil acceso a la información con el fin de soportar el
proceso de toma de decisión. En esta técnica de análisis, en lugar de ejecutar
múltiples consultas, los datos son estructurados para permitir un acceso rápido y fácil
a las respuestas de las preguntas que son típicamente formuladas. De esta manera,
Olap, brinda flexibilidad en la visualización de la información.
Las herramientas OLAP pueden soportar requerimientos complejos de análisis,
analizar datos desde diferentes perspectivas y soportar análisis complejos contra
un volumen determinado de datos. Su objetivo fundamental es proveer al usuario
final el fácil análisis de los datos, con la potencia y confiabilidad de una base de datos
corporativa, y con la posibilidad de ver los datos desde diversos puntos de vista
o dimensiones. Permite vistas reformateadas y calculadas sin el riesgo de perder o
corromper los datos originales y hace que la información pueda ser compartida por
varios usuarios sin tener que duplicar archivos. En muchos casos los usuarios pueden
adicionar o cambiar datos sin el riesgo de sobrescribir la información original.
El uso más común de estas herramientas en una empresa se da en el análisis de
ventas y compras de materia prima. Gracias a este análisis se evalúa la rentabilidad
de productos, capacidad de producción o la demanda. Estos aspectos dependen
directamente de los requerimientos del negocio específicos para cada empresa.
Las herramientas OLAP están dirigidas principalmente a los usuarios finales por lo
que requieren de una interfaz simple y deben tener una buena integración con los
sistemas que las alimentan.

Conceptos y Componentes

1. Cubo
OLAP efectúa el almacenamiento lógico de los datos en arreglos ó matrices
multidimensionales denominadas cubos. El cubo contiene los datos que son de
interés para los usuarios; organiza la información dentro de dimensiones y medidas
en una estructura multidimensional para soportar las preguntas que tienen los
usuarios acerca de los datos de su compañía. Además proporcionan un mecanismo
para la consulta de datos con rapidez y con una respuesta uniforme ante diferentes
cantidades de datos que contenga el cubo o por la complejidad de una consulta.

Página | 39
 Cubo tridimensional: Geografía, producto, tiempo.4

Un cubo se compone de dimensiones, jerarquías (niveles) y medidas. En el ejemplo

de la figura 4 se tiene un cubo con tres dimensiones: Geografía, Producto y
Ciudad. Además se tienen tres medidas: Unidades, Valor venta y Costo. En la celda
de la parte inferior derecha de la imagen se muestran los datos para una posible
pregunta gerencial:
¿Cuántas unidades, a qué valor y con qué costo se vendieron pantalones en la
ciudad de
Cali en el tiempo T4? Con su respectiva información.

2. Medida
La medida es el valor que toma determinada variable que se está analizando.
Las medidas son resultados cuantificables, o indicadores clave de desempeño
usados para determinar el éxito de una operación de negocios. Orientan las
respuestas a preguntas relacionadas con cuestiones numéricas como la cantidad,
valor o costo

Página | 40
En el caso de la figura 4 se tienen tres medidas, indicando que se vendieron
1930 unidades, a un valor de venta de 6745 y con costo de 5831. Un cubo puede
contener una o varias medidas, dependiendo del diseño y los requerimientos.
Existen dos tipos de medidas:
Medida regular: toma su dato directamente de una fuente disponible. Es un
compendio de información que ya se tiene, tal como el número de unidades
vendidas, ingresos, gastos, niveles de inventario.

Medida calculada: obtiene como resultado un nuevo dato numérico para medidas
que no están en una fuente directa disponible. Es derivada de otras medidas.
Ejemplos de este tipo de medidas son: ganancia (ingresos – costos), margen de
ganancia (ingreso – costo
/ingreso), tiempo promedio de espera ( fecha de entrega – fecha de la orden), etc.

3. Dimensión

Los atributos de tipo texto que describen cosas son organizados en dimensiones.
Es necesario establecer un criterio puramente de diseño y basado en los
requerimientos del negocio para establecer los atributos que se incluyen como
dimensiones y los que se pueden descartar al realizar la bodega de datos.

4. Nivel

Las dimensiones están construidas por niveles. Estos niveles representan la

jerarquía establecida por las estructuras organizacionales y modelos de datos que
la organización usa. Cada nivel inferior provee cada vez datos más detallados
que relaciona a la dimensión. Las herramientas especializadas para análisis OLAP
permiten fijar este nivel de granularidad en forma dinámica mientras el usuario final
navega por su reporte. La dimensión tiempo provee un claro ejemplo del uso de
niveles. Se tiene el año en un nivel superior, luego le siguen el semestre, trimestre,
mes y por último en el nivel más inferior se encuentra el día.

Página | 41
DESARROLLO

Caracteristicas de identificacion de grano

La siguiente lista contiene varias características de identificación de grano:

Especificar qué contienen los registros

Cuando se identifica el grano, se especifica exactamente qué contiene un registro
de tabla de hechos. El grano transmite el nivel de detalle asociado con las medidas
de la tabla de hechos. Cuando identificamos el grano, también se decide el nivel de
detalle que desea que esté disponible en el modelo dimensional. Si se incluyen más
detalles, el nivel de granularidad es menor. Si se incluyen menos detalles, el nivel
de granularidad es mayor.

Identificando el nivel de detalle

El nivel de detalle que está disponible en un esquema de estrella se conoce como
el grano. Cada tabla de hechos y dimensiones tiene su propio grano o
granularidad. Cada tabla (ya sea un hecho o una dimensión) contiene algún nivel
de detalle que está asociado a ella. Pero el grano del modelo dimensional es el nivel
más fino de detalle que se implica cuando se unen las tablas de hechos y
dimensiones. Por ejemplo, la granularidad de un modelo dimensional que consta de
las dimensiones Fecha, Tienda y Producto es producto vendido en la tienda por día.

Identificando los datos

Cada fila contiene el mismo tipo de datos. Por ejemplo, cada fila podría contener
ventas diarias por tienda por producto o líneas de pedido diarias por tienda.
Por ejemplo, las definiciones de granos pueden incluir los siguientes elementos:
o Una línea de pedido en un recibo de compra
o Una instantánea mensual de un extracto de cuenta bancaria
o Un único boleto de avión comprado en un día

Podemos manejar diferentes granularidades de datos mediante el uso de varias

tablas de hechos (tablas diarias, mensuales y anuales). También es posible usar
una sola tabla con un indicador de granularidad o una columna que indique el grano
de la tabla. Sin embargo, no se debe almacenar datos con diferentes granularidades
en la misma tabla de hechos.

Pasos a tener en cuenta para una correcta granularidad

Cuando se identifique los granos de los objetos de datos, debemos realizar los
siguientes pasos:

Página | 42
 1. Determinar la granularidad de la tabla de hechos .
2. Determinar cómo manejar múltiples granos separados .
3. Determinar el tipo de tabla de hechos para usar .
4. Verificar la atomicidad de tus granos .
5. Determinar las dimensiones y medidas de alto nivel en función de las
definiciones de grano .
6. Crear un informe de las definiciones de grano .

Identificar los metadatos del grano

Se debe reunir los siguientes metadatos durante esta fase:
 Una o más definiciones de grano para el proceso de negocio que se
esté modelando
 Definir los tipos de tabla de hechos que se usarán
 Medidas y medidas preliminares de alto nivel

Determinar la granularidad de la tabla de hechos

El detalle del grano se basa en los hallazgos de requisitos que se analizaron y
documentaron en el

Paso 1: identificar los requisitos del proceso comercial.

Una buena práctica es recopilar documentos, como facturas, recibos y notas de

pedido. Estos documentos a menudo tienen información que se puede usar para
definir el grano. Estos documentos también tienen información que ayuda a
identificar las dimensiones y medidas para los modelos dimensionales.
El grano que se elija determina el nivel de información detallada que puede estar
disponible para el modelo dimensional.
La definición de grano es la base de cada modelo dimensional. La definición de
grano determina el nivel de información disponible. Las pautas para elegir la
definición de grano incluyen las siguientes consideraciones:

 Durante la fase de recopilación de requisitos comerciales, se debe intentar

recopilar cualquier documento, como formularios de factura, formularios de
pedido y recibos de venta. Por lo general, estos documentos tienen datos
transaccionales asociados, como el número de pedido y el número de
factura.
 Los documentos a menudo pueden indicar los elementos importantes del
negocio, como el cliente y los productos. Los documentos a menudo
contienen información al nivel más bajo que pueda requerir la empresa.
 Otro punto importante a considerar es la fecha. Comprenda qué nivel de
detalle se asocia con un cliente, producto o proveedor. ¿La información en
los sistemas fuente está disponible a nivel de día, mes o año?

Página | 43
Manejo de múltiples granos separados
Determine si hay múltiples granos asociados con el proceso comercial para el cual
se está diseñando el modelo dimensional. Puede haber más de una definición de
grano asociada con un único proceso comercial. En estos casos, se debe diseñar
tablas de hechos separadas con granos separados. No hay que forzar todas las
medidas en una sola tabla de hechos.
Se pueden manejar diferentes granularidades de datos mediante el uso de varias
tablas de hechos (tablas diarias, mensuales y anuales, por ejemplo). Además, hay
que tener en cuenta la cantidad de datos, el espacio y los requisitos de rendimiento
cuando decidamos cómo manejar granularidades múltiples.

Criterios para una o múltiples tablas de hechos

Para determinar si se deben usar una o varias tablas de hechos, hay que tener en
cuenta los siguientes criterios:
 Considera las medidas. Decidir si se agrupan las medidas en una tabla de
hechos o separar tablas de hecho con diferentes granos.
 ¿Hay varios sistemas fuente OLTP involucrados? Cada sistema fuente está
diseñado con un propósito particular y específico. Si dos sistemas de origen
no tienen objetivos diferentes, se debe consolidar los sistemas en una sola
fuente. A su vez se debe mantener los sistemas separados, cada sistema
fuente atiende a un requisito particular de la empresa. Si los procesos
comerciales incluyen la gestión de pedidos, el inventario de la tienda o el
inventario del almacén, probablemente se trate de sistemas fuente
separados. En este caso, se debe usar tablas de hechos separadas.
 Determinar si se trata de procesos comerciales múltiples y no
relacionados. Crear tablas de hechos separadas para procesos comerciales
no relacionados. Si un único proceso de negocio requiere diferentes niveles
de granularidad, es necesario crear tablas de hechos separadas para
manejar esos niveles.
 Si una dimensión no es fiel a la definición de grano, diseñar una nueva tabla
de hechos con su propia definición de grano.
 Considerar el tiempo y la secuencia de eventos. Es posible que se necesite
procesos separados para manejar un solo evento. Por ejemplo, una empresa
comercializa un producto. Los clientes piden los productos. El departamento
de cuentas por cobrar produce una factura. El cliente paga la
factura. Después de la compra, el cliente puede devolver algunos de los
productos o enviar algunos de los productos para reparaciones. Si alguno de
los productos está fuera de garantía, este proceso requiere nuevos
cargos. Varios procesos están involucrados en la secuencia del evento de
compra individual. Cada uno de estos procesos probablemente trabaje con
un punto diferente en el tiempo. Cada uno de estos procesos se maneja
usando tablas de hechos separadas.

Página | 44
Múltiples granularidades en una sola tabla de hechos
Si se usan múltiples granos en una tabla de hechos, es necesario agregar una
columna llamada indicador de granularidad. Esta columna indicaría el grano de la
tabla. La columna define si la información se almacena a nivel diario, semanal,
mensual o anual.

Nota
Podemos almacenar granos múltiples en una sola tabla de hechos, pero este
enfoque no es recomendable. En cambio, se recomienda diseñar tablas de
hechos separadas y esquemas de estrellas para cada definición de grano.

Identificar los tipos de tablas de hechos para usar

Identifique el tipo de tabla de hechos involucrada en el diseño del modelo
dimensional. Para obtener más información acerca de los tipos de tabla de hechos,

Comprobando la atomicidad del grano

Revisar la atomicidad (nivel de detalle) del grano para asegurarse de que esté en el
nivel más detallado. Esta decisión incluye la consideración de las necesidades
futuras anticipadas a fin de minimizar el potencial de un rediseño requerido a medida
que cambian los requisitos del negocio.
El grano del modelo dimensional es importante cuando se diseña el modelo
dimensional. Incluso si los requisitos del negocio necesitan información a nivel
mensual o trimestral, hacer que esta información esté disponible a nivel diario. Si
las dimensiones son más detalladas (atómicas), la empresa puede recuperar
información más detallada.

Por ejemplo, si se considera una dimensión Fecha que tiene solo un atributo
Año. Como solo hay un atributo, no se puede consultar la información a nivel de
trimestre, mes o día. Para maximizar la información disponible, elegir un grano
atómico detallado. En este ejemplo, se puede definir el grano al nivel Día.
Por ejemplo, asumir que un grano de un producto vendido en una tienda. No se
puede asociar a un cliente con un producto en particular que se compra, porque
solo hay una fila para un producto. Si mil clientes compran el producto mil veces, no
se puede descubrir esa información.

Siempre se puede declarar granos de nivel superior para un proceso de negocio

mediante el uso de agregaciones de los datos más atómicos y detallados. Sin
embargo, cuando se selecciona un grano de nivel superior, el número de
dimensiones es limitado y puede ser menos granular. No se puede profundizar en
estas dimensiones menos granulares para obtener un menor nivel de detalle.

La Granularidad ofrece la oportunidad de una solución de compromiso entre los

problemas importantes en el almacenamiento de datos:

Página | 45
  El rendimiento versus el volumen de datos (y el costo relacionado de
almacenar esos datos)
 La capacidad de acceder a los datos a un nivel detallado en comparación con
el rendimiento (y el costo de almacenar y acceder a grandes volúmenes de
datos)
Seleccionar el nivel apropiado de granularidad afecta significativamente el
volumen de datos en el almacén de datos. Seleccionar el nivel apropiado de
granularidad también puede determinar la capacidad del almacén de datos
para satisfacer los requisitos de consulta.

Cuando considera el espacio en disco y el volumen de datos, una mayor

granularidad proporciona una forma más eficiente de almacenar datos que una
granularidad inferior. También debe considerar el espacio en disco para el índice de
los datos. Al usar un índice, ahorra más espacio en el disco. También considere la
manipulación de grandes volúmenes de datos. La manipulación de datos puede
afectar el rendimiento a costa de más potencia de procesamiento.
Siempre hay intercambios cuando procesas datos. Por ejemplo, a medida que la
granularidad se vuelve más alta, la capacidad de responder a diferentes tipos de
consultas (que requieren datos en un nivel más detallado) disminuye. Si la tabla
utiliza un bajo nivel de granularidad, puede admitir cualquier consulta que use esos
datos a costa de un mayor espacio de almacenamiento y un rendimiento reducido.
Si bien la granularidad no afecta la capacidad de responder una consulta, el sistema
puede necesitar más recursos para ejecutar la misma consulta. Supongamos que
tiene dos tablas con diferentes niveles de granularidad: una tabla con detalles de
transacción y una tabla que resume las cuentas por mes. Para crear un informe de
cuenta mensual, puede usar cualquier tabla sin ninguna dependencia de la
granularidad. Sin embargo, la consulta de la tabla de transacciones detallada busca
a través de más datos, que requieren procesamiento para calcular los resultados. La
tabla de resumen mensual de la cuenta requiere menos recursos. Cuando decide el
nivel de granularidad, considere la compensación entre el costo del volumen de
datos y la capacidad de responder consultas.

Identificar dimensiones y medidas de alto nivel

Identificar las dimensiones y medidas preliminares de alto nivel a partir de lo que se
entiende de la definición de grano. No se realiza un análisis detallado para identificar
estas dimensiones y medidas preliminares. Cuando se define el grano de manera
apropiada, se puede encontrar fácilmente las dimensiones y medidas preliminares.
Las medidas preliminares son medidas que pueden identificarse fácilmente al
observar la definición de grano. Por ejemplo, medidas tales como precio unitario,
cantidad y descuento son fácilmente identificables al mirar el grano. Sin embargo,
medidas detalladas como el costo, el precio de fabricación y el costo de transporte
no son medidas preliminares identificadas por el grano. Este tipo de medidas están
ocultas y, por lo general, nunca son visibles en un informe. Las medidas
preliminares no son el conjunto final de medidas. La identificación formal y detallada
de la medida ocurre cuando se identifica las medidas .

Página | 46
Crear un informe de la fase de identificación de grano
El informe de definición de grano se crea para esta fase. El informe contiene una o
más definiciones para el grano del proceso de negocio y define el tipo de tabla de
hechos. El informe también incluye las dimensiones y medidas preliminares de alto
nivel.

Página | 47
RESULTADOS

La dimensión Tiempo (tratamiento de Fechas y Horas) suele encontrarse en la

inmensa mayoría de nuestros proyectos y siempre estará presente en nuestro Data
Warehouse. A continuación, vamos a ver en esta sección cómo diseñarla e
implementarla enfocado a la granularidad

El motivo es obvio, hoy en día, cualquier análisis que vayamos a realizar, salvo raras
excepciones, necesitará tener una perspectiva temporal disponible

Si tan común es esta dimensión y aparece en cualquier diseño, ¿por qué en muchas
ocasiones no se le da la importancia que merece y no conseguimos sacar de ella el
máximo partido?
A continuación, vamos a ir viendo los diferentes aspectos que debemos tener en
cuenta a la hora de diseñarla:

1. Diseñar las tablas y columnas que va a tener, y su contenido

2. Elegir su granularidad
3. Elegir el proceso de carga
4. Decidir la frecuencia de carga

Diseño de la dimensión Tiempo (Fechas y Horas)

A continuación, se dan dos aproximaciones de diseño de las tablas que contendrán
la información relativa al tiempo, de forma separada por fines didácticos, una para
las fechas y otra para las horas, con una serie de columnas que basadas en nuestra
experiencia, son un buen punto de partida como diseño de nuestra Dimensión
Tiempo.

Es el momento de decidir qué columnas van a formar parte de cada una de estas
tablas, con el fin de más adelante poder responder de la forma que espera el usuario
a cualquier pregunta relativa al tiempo. No nos debe importar que haya una gran
cantidad de columnas, aunque en principio esto pueda sorprender a algún lector, he
de decir, que no es extraño encontrarnos con tablas para el tratamiento del tiempo
con varias decenas de columnas, e incluso centenares. Entre ellas podemos tener
columnas para gestionar diferentes calendarios (por campañas o temporadas,
fiscales u otros), para el uso de múltiples idiomas, para representar un mismo dato
de diferente forma de visualización, por ejemplo, relativo al trimestre podremos tener
varias columnas, con formatos de valores como ‘T1’, ‘Trim 1’, ‘2009-T1’, ‘Q1/2009’,
‘Q1’, ‘Quarter 1’, etc. (esto es extrapolable al resto de datos).

En el código que veremos a continuación se incluyen algunas columnas habituales

y el formato en el que se almacenará la información en ellas. Por supuesto, que todo
esto hay que contrastarlo con el usuario, incluir todas las columnas que estimemos

Página | 48
oportunas, y que en ellas el contenido sea tal y como al usuario le interesa
visualizarlo.

Tabla de dimensión Fecha

--create schema Dimension
CREATE TABLE Dimension.Fecha(
[DateKey] [int] NOT NULL, /* Format: AAAAMMDD */
[Date] [datetime] NOT NULL, /* Actual date */
[FullDate_Description] [nvarchar](100) NULL, /* Actual date
description*/
[DayNumberOfWeek] [tinyint] NULL, /* 1 to 7 */
[DayNumberOfMonth] [tinyint] NULL, /* 1 to 31 */
[DayNumberOfYear] [smallint] NULL, /* 1 to 366 */
[WeekNumberOfYear] [tinyint] NULL, /* 1 to 53 */
[MonthNumberOfYear] [tinyint] NULL, /* 1 to 12 */
[CalendarQuarterOfYear] [tinyint] NULL, /* 1 to 4 */
[CalendarSemesterOfYear] [tinyint] NULL, /* 1 to 2 */
[CalendarYear] [char](4) NULL, /* Just the number */
[CalendarYearWeek] [nvarchar](25) NULL,/* Week Unique Identifier:
Week + Year */
[CalendarYearMonth] [nvarchar](25) NULL,/* Month Unique
Identifier: Month + Year */
[CalendarYearQuarter] [nvarchar](25) NULL,/* Quarter Unique
Identifier: Quarter + Year */
[CalendarYearSemester] [nvarchar](25) NULL,/* Semester Unique
Identifier: Semester + Year */
[CalendarYearWeek_Description] [nvarchar](25) NULL,/* Week Unique
Descriptor: example - '2007-52' */
[CalendarYearMonth_Description] [nvarchar](25) NULL,/* Month
Unique Descriptor: example - '2007-12' */
[CalendarYearQuarter_Description] [nvarchar](25) NULL,/* Quarter
Unique Descriptor: example - 'Q2/2007' */
[CalendarYearSemester_Description] [nvarchar](25) NULL,/*
Semester Unique Descriptor: example - 'H1.07' */
[CalendarYear_Description] [nvarchar](25) NULL,/* Calendar Year
Descriptor: example - 'CY 2007' */
[EnglishDayNameOfWeek] [nvarchar](10) NULL,
[SpanishDayNameOfWeek] [nvarchar](10) NULL,
[CatalanDayNameOfWeek] [nvarchar](10) NULL,
[EnglishMonthName] [nvarchar](10) NULL, /* January to December */
[SpanishMonthName] [nvarchar](10) NULL, /* Enero a Diciembre */
[CatalanMonthName] [nvarchar](10) NULL /* Gener a Desembre */
--Agregar o quitar las columnas que estimemos
--oportunas en nuestro diseño

Página | 49
CONSTRAINT [PK_DimDate_DateKey] PRIMARY KEY CLUSTERED
([DateKey] ASC)WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF)
ON [PRIMARY],
CONSTRAINT [AK_DimDate_Date] UNIQUE NONCLUSTERED
([Date] ASC)WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON
[PRIMARY]
) ON [PRIMARY]
T-SQL 1. Estructura de la tabla de dimensión Fecha
Tabla de dimensión Hora

--create schema Dimension

CREATE TABLE [Dimension].[Hora](
[IdHora] [int] NOT NULL,
--Se puede cambiar el tipo de datos si tenemos SQL Server 2008
[Tiempo] [datetime] NOT NULL,
[Hora] [tinyint] NOT NULL,
[Minuto] [tinyint] NOT NULL,
[Segundo] [tinyint] NOT NULL,
[AM] [char](2) NOT NULL,
[NombreHora] [char](2) NOT NULL,
[NombreHoraAM] [char](5) NOT NULL,
[NombreMinuto] [char](2) NOT NULL,
[NombreSegundo] [char](2) NOT NULL,
[HoraMinuto] [char](5) NOT NULL,
[HoraMinutoAM] [char](8) NOT NULL,
[HoraMinutoSegundo] [char](8) NOT NULL,
[HoraMinutoSegundoAM] [char](11) NOT NULL,
--Agregar o quitar las columnas que estimemos
--oportunas en nuestro diseño

CONSTRAINT [PK_Hora] PRIMARY KEY CLUSTERED

(
[IdHora] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF,
IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
ON [PRIMARY]
) ON [PRIMARY]
GO
T-SQL 2. Estructura de la tabla de dimensión Hora

Como se ha podido comprobar, hemos dejado nuestras tablas diseñadas para

registrar un nivel de granularidad hasta el nivel de segundos (muy rara vez

Página | 50
podríamos necesitar milisegundos, pero si se diese el caso también se podría con-
templar). Independientemente de la granularidad que vayamos a utilizar, podemos
dejar nuestras tablas diseñadas de forma que incluyan columnas que describan ese
máximo nivel.

Elegir la granularidad de cada tabla

La granularidad de la dimensión tiempo puede ser variada según la tabla de hechos
con la que se vaya a relacionar. En su diseño, deberemos tener en cuenta el máximo
nivel que vayamos a necesitar y además tener columnas que nos permitan acceder
a un nivel incluso menor del requerido en ese momento.

Imaginemos que tenemos en nuestro Data Warehouse tablas de hechos con la

información de Presupuestos, Ventas y Producción. Los presupuestos los
realizamos a nivel mensual, mientras en el análisis de Producción los requisitos nos
indican que el máximo nivel de detalle que necesitaremos será el día. En cambio,
en Ventas, necesitaremos saber hasta el detalle de la hora y el minuto en que se
realizó cada operación. En este caso nuestra Dimensión Tiempo deberá tener
información detallada hasta el nivel de minutos. Ello no impide que la estructura de
nuestra tabla esté preparada para soportar una granularidad de segundos, y que
con un simple cambio en el proceso de ETL que alimentada con dicha información,
como veremos más adelante.

Elegir el proceso de carga

Una vez que tenemos diseñada nuestra tabla y estudiados los posibles niveles de
granularidad que vamos a necesitar, debemos proceder a realizar un proceso ETL
que permita alimentar estas tablas.

 Hay diversas formas de realizar el proceso para la carga de la Dimensión

Tiempo, estas son algunas de las más comunes:
Realizarlo mediante T-SQL. Hacer un procedimiento almacenado que inserte
una fila para una fecha. Luego se hace un bucle con T-SQL que recorra un
rango de fechas seleccionado y que por cada una de estas fechas llame al
procedimiento almacenado y la inserte
 Realizarlo mediante Integration Services. Utilizaremos un bucle For Loop, en
el que por cada fecha, llamaremos a un Data Flow en el que haremos los
cálculos de las columnas derivadas que necesitemos para esa fecha e
insertaremos la fila correspondiente a esa fecha
 Si eres un usuario que no tiene conocimientos de SQL, también la puedes
crear con Excel

Otra cosa a tener en cuenta, es que dada la poca frecuencia con la que se suele
ejecutar este proceso de carga, igual una vez al año o incluso nunca (casi nunca).
Además, cuando ejecutemos estos procesos el número de filas afectadas no será
muy grande. Esto hace que no sea muy significativo el método de carga utilizado,
Página | 51
si es con Integration Services, si es con T-SQL, si usa cursores (aunque nunca lo
recomendaría), etc.

Tenga en cuenta que lo visto anteriormente son simplemente aproximaciones, y

podemos hacer sobre ellas las variaciones que estimemos oportunas. Podemos no
utilizar procedimientos almacenados e incluir en el script todos los cálculos de
columnas. Podemos utilizar una CTE en lugar de un bucle, o cualquier otra variante
que estimemos oportuna.

Carga de la dimensión Tiempo basada en T -SQL

Veamos a continuación un ejemplo de carga basado en instrucciones T-SQL, que
nos puede servir de base para la carga de nuestra dimensión tiempo, simplemente
con añadir nuevos cálculos para las columnas que finalmente incluyamos en el
diseño de nuestra dimensión. En este caso vamos a considerar que la máxima
granularidad de nuestra tabla será el día, y vamos a llamar a dicha tabla
Dimension.Fecha, partiendo inicialmente de muy pocas columnas, para más
adelante, cuando hagamos su diseño definitivo, incorporar las columnas que
estimemos oportunas.

Bucle de carga de Fechas

declare @StartDate datetime, @EndDate datetime
--Deberá ser la fecha más antigua de la que tengamos datos

set @StartDate = '19900101'

--Podemos bien dejar cargado un periodo muy amplio

--set @EndDate = '21001231'
--O bien, cargar los cinco próximos años completos
set @EndDate = cast(cast(year(getdate()) + 5 as char(4)) + '1231' as datetime)
while @StartDate <= @EndDate begin
exec InsertarFecha @StartDate
-- Podemos incrementar contador en años, meses o días
-- poniendo year, month o day en la función dateadd
set @StartDate = dateadd(day,1,@StartDate)
-- Lo más habitual es tener la granularidad día
end
T-SQL 3. Bucle de carga de un rango de fechas, según granularidad indicada
en el incremento de la variable @startdate

Página | 52
Procedimiento almacenado de carga de cada fila en la tabla Fecha
create procedure InsertarFecha
@CurrentDate datetime
as
insert into Dimension.Fecha([DateKey], [Date],
[DayNumberOfWeek], [EnglishDayNameOfWeek], [DayNumberOfMonth],
[DayNumberOfYear], [WeekNumberOfYear], [EnglishMonthName],
[MonthNumberOfYear], [CalendarQuarterOfYear], [CalendarYear],
[CalendarSemesterOfYear], [CalendarYearWeek], [CalendarYearMonth],
[CalendarYearQuarter], [CalendarYearSemester])
values(
(DATEPART(year , @CurrentDate) * 10000) + (DATEPART(month ,
@CurrentDate)*100)
+ DATEPART(day , @CurrentDate)
, @CurrentDate
, DATEPART(dw , @CurrentDate)
, DATENAME(dw, @CurrentDate)
, DATEPART(day , @CurrentDate)
, DATEPART(dayofyear , @CurrentDate)
, DATEPART(wk , @CurrentDate)
, DATENAME(month, @CurrentDate)
, DATEPART(month , @CurrentDate)
, DATEPART(quarter , @CurrentDate)
, DATEPART(year , @CurrentDate)
, CASE WHEN DATEPART(quarter , @CurrentDate) < 3 THEN 1
ELSE 2
END
, CAST(DATEPART(year , @CurrentDate) as char(4)) + '-'
+ RIGHT('0'+CAST(DATEPART(wk , @CurrentDate) AS varchar(2)),2)
, CAST(DATEPART(year , @CurrentDate) as char(4)) + '-'
+ RIGHT('0'+CAST(DATEPART(month , @CurrentDate) AS varchar(2)),2)
, CAST(DATEPART(year , @CurrentDate) as char(4)) + '-'
+ CAST(DATEPART(quarter , @CurrentDate) AS varchar(1))
, CAST(DATEPART(year , @CurrentDate) as char(4)) + '-'
+ CAST(CASE WHEN DATEPART(quarter , @CurrentDate) < 3 THEN 1
ELSE 2
END AS char(2))
)
GO
T-SQL 4. Procedimiento almacenado que inserta una fila, calculando
columnas derivadas elegidas, para la fecha recibida como parámetro

Página | 53
Actualizaciones para personalizar
A continuación mostramos la actualización de algunas columnas en función del
idioma al que hacen referencia. Veremos que para algunas de ellas podemos
aprovechar la propia configuración del lenguaje establecida en SQL Server, pero
para otras debemos hacer nosotros esta tarea al no estar ese idioma disponible.

-- Update non-english language names

-- .. SPANISH / Spain / es-ES
SET LANGUAGE Spanish
UPDATE Dimension.Fecha
SET SpanishDayNameOfWeek = DATENAME(dw, [Date])
, SpanishMonthName = DATENAME(month, [Date])
WHERE Date >= @StartDate AND Date<= @EndDate

-- Reset the language

SET LANGUAGE us_english

-- .. CATALAN
UPDATE Dimension.Fecha
SET CatalanDayNameOfWeek =
CASE DayNumberOfWeek
WHEN 2 THEN 'Dilluns'
WHEN 3 THEN 'Dimarts'
WHEN 4 THEN 'Dimecres'
WHEN 5 THEN 'Dijous'
WHEN 6 THEN 'Divendres'
WHEN 7 THEN 'Dissabte'
WHEN 1 THEN 'Diumenge'
END,
CatalanMonthName =
CASE MonthNumberOfYear
WHEN 1 THEN 'Gener'
WHEN 2 THEN 'Febrer'
WHEN 3 THEN 'Març'
WHEN 4 THEN 'Abril'
WHEN 5 THEN 'Maig'
WHEN 6 THEN 'Juny'
WHEN 7 THEN 'Juliol'
WHEN 8 THEN 'Agost'
WHEN 9 THEN 'Setembre'
WHEN 10 THEN 'Octubre'
WHEN 11 THEN 'Novembre'
WHEN 12 THEN 'Desembre'
END
WHERE Date >= @StarDate AND Date<= @EndDate

Página | 54
T-SQL 5. Asignación según idioma a mostrar en esa columna

Anteriormente sólo hemos llegado al nivel de granularidad de fecha, es decir, de

una fila por cada día. Si queremos bajar a mayor detalle tendríamos que tener
niveles de horas, minutos, segundos, o incluso menores. En este caso, lo que
vamos a hacer es crear una tabla llamada Dimension.Hora en la que tendre-mos
sólo las horas, sin las fechas, y veremos también su proceso de carga, basado en
un bucle que recorre las veinticuatro horas del día y carga dicha tabla, llaman-do a
un procedimiento almacenado que obtiene todas las columnas derivadas que
estimemos oportunas.

Bucle de carga de hora

declare @Time datetime

set @Time = convert(varchar,'12:00:00 AM',108)

while @Time <= '11:59:59 PM' begin

exec InsertarHora @Time
-- Podemos incrementar contador en Horas, Minutos o Segundos
-- poniendo hour, minute o second en la función dateadd
set @Time = dateadd(hour,1,@Time)
end
T-SQL 6. Bucle que carga las 24 horas del día, según granularidad indicada en
el incremento de la variable @Time

Procedimiento almacenado de carga de cada fila en la tabla Hora

create procedure InsertarHora
@Time datetime
as
declare @IdHora int, @Hora tinyint,
@Minuto tinyint, @Segundo tinyint, @AM char(2),
@NombreHora char(2), @NombreHoraAM char(5),
@NombreMinuto char(2), @NombreSegundo char(2),
@HoraMinuto char(5), @HoraMinutoAM char(8),
@HoraMinutoSegundo char(8), @HoraMinutoSegundoAM char(11)

--Calcular columnas mínimas necesarias

set @Hora = datepart(hour, @Time)
set @Minuto = datepart(minute, @Time)
set @Segundo = datepart(second, @Time)
set @IdHora = (@Hora*10000) + (@Minuto*100) + @Segundo

Página | 55
 --Se puede dejar tanto para granularidad minutos como
--segundos, o bien
--(@Hora*100) + @Minuto, para granularidad minutos,
--pero luego no habría huecos para aumentar la
--granularidad a segundos
--@Hora, para granularidad horas, pero luego no habría
-- huecos para aumentar la granularidad a minutos o segundos
--Aquí se agregarán todos los cálculos en base a esa hora
--que estimemos oportunos
--Mostramos algunos de los formatos más habituales,
--pero no su cálculo, sino que le asignamos un valor fijo
--a modo de ejemplo
set @AM = right(convert(varchar,@Time,109),2) -- AM/PM
set @NombreHora = '00' -- HH con ceros por la izquierda
set @NombreHoraAM = '12 AM' -- HH AM las 00 son las 12 AM
set @NombreMinuto = '00' -- MM con ceros por la izquierda
set @NombreSegundo = '00' -- SS con ceros por la izquierda
set @HoraMinuto = '00:00' -- HH:MM con ceros por la izquierda
set @HoraMinutoAM = '12:00 AM'
-- HH:MM AM las 00:00 son las 12:00 AM
set @HoraMinutoSegundo = convert(varchar, @Time, 108) -- HH:MM:SS
set @HoraMinutoSegundoAM = '12:00:00 AM'
-- HH:MM:SS AM las 00:00:00 son las 12:00:00 AM

--Insertar fila
insert into Dimension.Hora(IdHora, Tiempo, Hora, Minuto, Segundo,
AM, NombreHora, NombreHoraAM, NombreMinuto, NombreSegundo,
HoraMinuto, HoraMinutoAM, HoraMinutoSegundo,
HoraMinutoSegundoAM)
select @IdHora, @Time, @Hora, @Minuto, @Segundo, @AM,
@NombreHora, @NombreHoraAM, @NombreMinuto,
@NombreSegundo, @HoraMinuto, @HoraMinutoAM,
@HoraMinutoSegundo, @HoraMinutoSegundoAM
GO
T-SQL 7. Procedimiento almacenado que inserta una fila, calculando las
columnas derivadas elegidas, para la hora recibida como parámetro

Página | 56
Por qué separar en dos tablas fecha y hora
Como se ha podido comprobar, hemos hecho un tratamiento del tiempo basado en
dos tablas, por un lado el tratamiento de Fechas y por otro lado el tratamiento de
Horas. Si no es su caso y necesita tener una sola tabla, con la granularidad que
estime oportuna, bien puede adaptar el material anterior y cambiar el diseño para
que el nivel de granularidad sea mayor y que todo gire en torno a una sola tabla, o
bien, puede mantenerlo, y mediante una CROSS JOIN puede obtener el resultado
de una sola tabla que incluya el producto cartesiano de ambas tablas.

Elegir la frecuencia de carga de la dimensión Tiempo

La dimensión Tiempo es bastante atípica, en líneas generales, con respecto a la
periodicidad de los procesos de carga, incluso puede que teóricamente nunca
debamos volver a cargarla (al menos a lo largo de nuestra carrera profesional,
cuidado que no nos ocurra como con el tratamiento del año 2000 :)). Como se indica
en el Bloque de Código 3 si se indica un rango cuyo extremo inferior está en el año
más antiguo del que tenemos datos en nuestra empresa y el superior en el año
2100, rara vez tendremos que cargar filas adicionales. En cambio hay otras
alternativas que evitan tener todas esas filas cargadas sin necesidad durante largos
periodos de tiempo. Por ejemplo se puede hacer una carga de los cinco siguientes
años, y anualmente lanzar el proceso y agregar nuevas filas.

El único tema adicional que se considera importante, es que en los procesos ETL
de carga de hechos, habrá que tener en cuenta el tratamiento a realizar cuando
entre un hecho con una fecha que no se encuentre almacenada en la Dimensión
Tiempo. Podemos incluso hacer que el proceso cree una fila para esa fecha en la
dimensión tiempo. Lo más habitual es que ese hecho arrastre algún error en el
sistema transaccional, para lo cual debemos de alguna forma reflejar que se ha
producido esa situación, bien grabando en alguna tabla de auditoría, bien llevando
esas filas a otra tabla para revisión, o como estimemos oportuno, pero siempre
dejando reflejada esa posible anomalía.

Consideraciones adicionales sobre la dimensión Tiempo

En lo visto anteriormente, hemos abordado de forma genérica el tratamiento de la
dimensión tiempo, aunque en ciertos casos, habrá nuevas problemáticas que no
estén cubiertas aquí. Vamos a citar una de las más habituales, pero no llegaremos
a desarrollarla en este momento por el espacio que ocuparía. Lo dejamos pendiente
para futuros artículos.

Es habitual que una empresa tenga diferentes sedes, y que estas estén en lugares
geográficos distintos, en diversas ciudades a lo largo de la geografía. En ese caso,
aunque una fecha es la misma en cualquier lugar del planeta, nos solemos encontrar
Página | 57
con pequeñas variantes, como es el caso del tratamiento de los festivos, de periodos
de cierre de producción en cada sede, o cualquier otro dato a tratar que pueda variar
de un lugar a otro. Para estos casos, hemos visto una alternativa simple, que es
tener una columna de festivos para cada lugar. Esta solución es rápida y válida en
algunos casos, pero hay otros muchos que necesitan de una mayor flexibilidad, y
que se puedan incorporar de forma automática nuevas sedes y por tanto nuevos
calendarios, y no querremos estar añadiendo nuevas columnas a nuestra tabla y
modificando nuestro proceso de ETL para que las alimente. En ese caso debemos
cambiar la granularidad de nuestra tabla para tener una fecha por cada calendario
que tengamos en nuestro sistema, así para un mismo día habrá tantas filas como
calendarios tengamos definidos.

Página | 58
CONCLUSION

El problema de diseño más importante que enfrenta el desarrollador del depósito de

datos es determinar el nivel adecuado de granularidad de los datos que residirán en
el almacén de datos. Cuando el nivel de granularidad se establece correctamente,
los aspectos restantes del diseño y la implementación fluyen sin problemas; cuando
no está configurado correctamente, cualquier otro aspecto es incómodo.

La granularidad también es importante para el arquitecto del almacén porque afecta

a todos los entornos que dependen del almacén para los datos. La granularidad
afecta la eficacia con que se pueden enviar los datos a los diferentes entornos y
determina los tipos de análisis que se pueden realizar.

El problema principal de la granularidad es conseguirlo en el nivel correcto. El nivel

de granularidad no debe ser ni demasiado alto ni demasiado bajo.

La compensación en la elección de los niveles correctos de granularidad se centra

en gestionar el volumen de datos y almacenar datos a un nivel de granularidad
demasiado alto, hasta el punto de que los datos detallados son tan voluminosos que
no se pueden usar. Además, si va a haber una cantidad verdaderamente grande de
datos, se debe considerar poner la porción inactiva de los datos en el
almacenamiento de desbordamiento.

Página | 59
BIBLIOGRAFIA / LINKOGRAFIA

 https://www.safaribooksonline.com/library/view/building-the-
data/9780764599446/ch04.html
 https://www.quora.com/What-is-granularity-in-data-warehouse
 http://smartbasegroup.com/tips-de-diseno-de-dwh-la-granularidad-parte-1/
 https://www.ibm.com/support/knowledgecenter/en/SS9UM9_8.5.0/com.ibm.
datatools.dimensional.ui.doc/topics/c_dm_design_cycle_2_idgrain.html
 https://www.1keydata.com/datawarehousing/fact-table-granularity.html
 http://www.business.aau.dk/oekostyr/file/What_is_a_Data_Warehouse.pdf
 https://www.adictosaltrabajo.com/tutoriales/datawarehouse-4/
 Building the Data Warehouse by W.H Inmon
 Ralph Kimball, 1996. The Data Warehouse Toolkit. Wiley.
 Ralph Kimball, 1998. The Data Warehous Lifecycle Toolkit. Wiley.
 Barry Devlin, 1997. Data Warehouse from architecture to
implementation.

Página | 60