Implementación de Inteligencia de Negocios con SQL Server 2014

Facultad de Ingeniería Industrial y de Sistemas
CAPÍTULO 1
 Inteligencia de Negocios
 Gestión de la Información con Inteligencia de Negocios
 Introducción a una Solución de Inteligencia de Negocios.
Business Intelligence con SQL Server 2014 - Implementación danielramos@dba.pe Pág. 1

Universidad Nacional de Ingeniería
I N T E L I G E N C I A D E N E G O C I O S
Que es Inteligencia de Negocios

Business Intelligence es la habilidad para transformar los datos en información, y la
información en conocimiento, de forma que se pueda optimizar el proceso de toma de
decisiones en los negocios.
Desde un punto de vista más pragmático, y asociándolo directamente con las

tecnologías de la información, podemos definir Business Intelligence como el conjunto
de metodologías, aplicaciones y tecnologías que permiten reunir, depurar y transformar
datos de los sistemas transaccionales e información desestructurada (interna y externa
a la compañía) en información estructurada, para su explotación directa (reporting,
análisis OLTP / OLAP, alertas...) o para su análisis y conversión en conocimiento, dando
así soporte a la toma de decisiones sobre el negocio.
La inteligencia de negocio actúa como un factor estratégico para una empresa u

organización, generando una potencial ventaja competitiva, que no es otra que
proporcionar información privilegiada para responder a los problemas de negocio:
entrada a nuevos mercados, promociones u ofertas de productos, eliminación de islas
de información, control financiero, optimización de costes, planificación de la
producción, análisis de perfiles de clientes, rentabilidad de un producto concreto, etc.
Para definir BI de otra forma, utilizaremos la definición de la consultora Gartner:

“BI es un proceso interactivo para explorar y analizar información estructurada
sobre un área (normalmente almacenada en un datawarehouse), para descubrir
tendencias o patrones, a partir de los cuales derivar ideas y extraer conclusiones.
El proceso de Business Intelligence incluye la comunicación de los descubrimientos y

efectuar los cambios.
Las áreas incluyen clientes, proveedores, productos, servicios y competidores.”
Pág. 2 danielramos@dba.pe Business Intelligence con SQL Server 2014 - Implementación

Como apoya Inteligencia de Negocios al flujo de

información de la empresa
Uno de los objetivos básicos de los sistemas de información es que nos ayuden a la
toma de decisiones. Cuando un responsable tiene que tomar una decisión pide o busca
información, que le servirá para reducir la incertidumbre. Sin embargo, aunque todos la
utilicen, no todos los responsables recogen la misma información: depende de muchos
factores, como pueden ser su experiencia, formación, disponibilidad, etc. Del mismo
modo, los responsables pueden necesitar recoger más o menos información
dependiendo de su mayor o menor aversión al riesgo.
A partir de los datos que nos proporciona el sistema de Business Intelligence podemos
descubrir conocimiento. Por ejemplo, en un concesionario de autos para taxis en Lima,
descubrimos la relación entre el número de visitas al concesionario y el número de
vehículos vendidos en el mes siguiente.
Parece claro que el número de visitas al concesionario parece un indicador clave, pero
¿todos los concesionarios lo recogen? Como hemos visto, Business Intelligence nos
servirá como ayuda para la toma de decisiones y, posteriormente, para descubrir cosas
que hasta ahora desconocíamos.
Quien necesita soluciones de Inteligencia de Negocios

Recuerde que el objetivo del Business Intelligence es colocar todos los datos al alcance
de toda la empresa, proporcionando las herramientas para extraerlos de las
aplicaciones, conferirles un formato estándar, y posteriormente almacenarlos en un
repositorio optimizado para una entrega de la información rápida y resumida que haga
posible un análisis muy detallado.
Para realizar un diagnóstico instantáneo de su empresa, sólo tiene que responder al

siguiente cuestionario:
 ¿Está seguro de qué productos y clientes son los más importantes para su
empresa?
Sí No N/a
 ¿Tiene problemas para crear una visión clara de toda su organización?

Sí No N/a
 ¿Sabe si está perdiendo cuota de mercado con respecto a su competencia?

Sí No N/a
 ¿Ha perdido oportunidades de negocio por recibir información atrasada?

Sí No N/a
 ¿Dedica horas extras a analizar documentos e informes?

Sí No N/a

 ¿Tiene informes de varios sistemas operacionales que no concuerdan?

Sí No N/a
 ¿Dispone de alguna ventaja competitiva clara con respecto a las demás empresas
de su sector?
Sí No N/a
 ¿Sabe con certeza si su gente está alcanzando los objetivos planificados?

Sí No N/a
Si al menos la mitad de las respuestas han sido afirmativas, su empresa puede

encontrar importantes beneficios al implantar un sistema de Business Intelligence.

G E S T I Ó N D E L A I N F O R M A C I Ó N C O N
El escenario competitivo de hoy

Microsoft tiene una visión sobre este tipo de escenarios, proporcionando una serie de
herramientas para ello.
Esta solución presenta herramientas para acceder a los orígenes de datos, la extracción
de datos, transformación de datos, carga de datos, elaboración del cubo, publicación de
datos a través del uso de reportes personalizados.
Necesidad de Inteligencia de Negocios

El objetivo básico del Business Intelligence es apoyar de forma sostenible y continuada
a las organizaciones para mejorar su competitividad, facilitando la información necesaria
para la toma de decisiones.

El valor de Inteligencia de Negocios

Vivimos en la sociedad de la información. Gracias a Internet y al desarrollo de los
sistemas de información en las empresas, sus directivos pueden acceder a mucha más
información, de más calidad y con mayor rapidez. El potencial que ello ofrece para
mejorar la toma de decisiones y para guiar a las empresas hacia la consecución de sus
objetivos es enorme. Sin embargo, muchos directivos se enfrentan a la paradoja de que
“cada vez tienen más información y menos tiempo para analizarla”.
Imaginemos una situación hipotética: se ha convocado una reunión para analizar la

evolución de las ventas de la empresa. Cuando los asistentes comienzan la reunión
descubren, asombrados, que ¡hay varias versiones! Durante la reunión, se discute sobre
la veracidad de la información y de las fuentes, y al final de la misma se encarga a
alguien la responsabilidad de informar al resto de los participantes para las próximas
reuniones, no completándose ninguno de los puntos del orden del día.
Aunque esta situación es hipotética, ¿nunca les ha ocurrido algo similar? Las causas
que pueden propiciar este tipo de situaciones son varias: no compartimos la definición
de “ventas”, tenemos distintos sistemas no integrados que pueden provocar diferencias,
no se han definido correctamente los períodos de tiempo para analizarlas, etc.

I N S TA L A C I Ó N D E L A P L A T A F O R M A D E
I N T E L I G E N C I A D E N E G O C I O S C O N
M I C R O S O F T
Windows Server
Es el sistema operativo de red que utilizaremos para realizar nuestro trabajo. Tener en
cuenta que el SQL Server, en cualquiera de sus ediciones, solo puede ser instalado
sobre este sistema operativo.
La versión de Windows Server que se puede utilizar es la 2008 o la 2012.
SQL Server
La versión a utilizar es la 2014, en la edición Enterprise, la cual solo funciona sobre un
sistema operativo de red.
Esta edición empresarial será instalada con toda la suite completa de herramientas,
como son el motor de base de datos, servicio de análisis, servicio de integración y
servicio de reportes.
Cualquier duda sobre la instalación de este producto, consultar el manual de SQL

Administración, capitulo 1, que trata debidamente el tema, o también consultando la
siguiente site: www.dba.pe

I N T R O D U C C I Ó N A U N A S O L U C I Ó N D E
I N T E L I G E N C I A D E N E G O C I O S .
Creando Modelo de Data Mart con SQL Server
Creando ETL con SQL Server

Como se verá en el capítulo 3, desarrollaremos un proyecto utilizando las herramientas
de integration services para poder elaborar un ETL.
Microsoft nos presenta una variedad de controles para realizar dicho trabajo, tal y como
se muestra en la lista siguiente:

Ahora, dentro de estos controles, nosotros podemos manejar un flujo de proceso, que
nos permita completar el trabajo encomendado para la extracción, transformación y
carga de datos.
Como se puede observar en el siguiente gráfico, la definición del circuito estará

supeditado a la tarea a desarrollar, solo debemos de tener presente la lógica a seguir.

Creando Cubo con Analysis Services

Crear un proyecto de Analysis Services implica contar
con un datawarehouse que se encargue de suministrar
los datos necesarios para construir el cubo. El proyecto
requiere de algunos elementos para poder
desarrollarlo, estos elementos son:
 Data Sources, con el cual nos conectamos al

datawarehouse para la extracción de datos.
 Data Source Views, para especificar que
dimensiones y hechos formarán parte del cubo
a desarrollar. El proyecto puede contar con
varias vistas.
 Cubes, donde se muestran los diferentes cubos
que se han creado en el proyecto. El cubo se
crea a partir de una vista.
 Dimensions, son las dimensiones que
acompañan al cubo, para describir las
diferentes medidas que pudieran existir. La
dimensión es exclusiva para un cubo, vale decir,
si tenemos varios cubos que utilizan una misma
tabla de dimensión, entonces se creara una
dimensión en el proyecto por cada referencia
que pudiera tener.

CAPÍTULO 2
 Planeando Solución de Inteligencia de Negocios
 Diseñando Data Mart

P L A N E A N D O S O L U C I Ó N D E
La misión de la inteligencia de negocios es proveer una única vista del negocio y

empoderar oportunamente a la gente y procesos del negocio con conocimiento correcto
basado en la información operacional actual e histórica para tomar decisiones y actuar
pro activamente, para así lograr mejor desempeño, mayor productividad, disminuir
costos, optimizar procesos.
La inteligencia de negocios tiene su mayor impacto en el negocio en la medida que se

alineé con la estrategia organizacional a mediano y largo plazos: es importante
establecer un programa de inteligencia de negocios que permita suplir las necesidades
de información y conocimiento para que los gerentes, administradores y el equipo
operacional tomen decisiones y definan acciones orientadas al alcance global de las
metas de la organización.
Esta alineación se logra diseñando y ejecutando el programa de inteligencia de

negocios, basado en buenas prácticas que se deben incorporar en la organización, para
que sus efectos esperados en el negocio se den a buen término: planear y definir el
alcance de BI implica determinar las iniciativas, temas y prioridades críticas del negocio
a nivel operacional, táctico y estratégico; conformar los grupos de interés y el patrocinio
de la alta gerencia; establecer los roles y responsabilidades de las partes; definir un
comité directivo conformado por usuarios y el equipo técnico de BI; establecer un comité
de revisión del proyecto; adoptar y adaptar una metodología; culturizar a la organización
y cada una de sus áreas; implementar el proyecto de manera incremental; definición de
la duración del proyecto alineando las necesidades del negocio y el cumplimiento de
niveles de calidad y estándares de la solución BI; conformar el equipo de BI;
entrenamiento en la solución de BI; mitigación de riesgos de ejecución del proyecto,
financieros y tecnológicos; y la justificación del proyecto o programa de BI.
Más aún, un enfoque de mayor alcance organizacional y estratégico es la

implementación de un programa de gobernancia de datos (Data Governance), el cual
permite evaluar, administrar, usar, mejorar, monitorear, mantener y proteger
consistentemente y apropiadamente la información a lo largo de la organización,
buscando dar mayor valor para mejor toma de decisiones, cumplimiento con
regulaciones, reserva, confidencialidad y seguridad de los datos, mejoramiento de la
captura de información y medición de la calidad de los datos. En sí, el objetivo más
común de los programas de gobernancia de los datos es estandarizar la definición de
los datos a lo largo de la organización.
BI Analytics ofrece sus servicios en la conformación de un programa de gobierno de los

datos (Data Governance) siguiendo el framework DGI Data Governance Framework.

Pasos del Proceso

Las soluciones que construya no necesariamente deben abarcar todos los elementos
de una suite de inteligencia de negocio y la información no necesariamente será de
todas las áreas de la empresa. Es posible que la solución de inteligencia, dependiendo
de su objetivo involucre solamente la información de tres áreas en lugar de las 10 que
integran su empresa, sin embargo, es importante aclarar que mientras más completa o
integral sea la información y refleje el resultado de las operaciones de su empresa, se
encontraran comportamientos en los datos que afecten de manera integral a toda la
empresa y no solamente a algunas áreas.
Entrevista
 Es importante poder entrevistar a todas las personas necesarias que nos

permitan identificar el problema
Documentación Requerida
 Toda aquella información que nos permita conocer la forma de recolección y

manejo de los datos.
Ubicación e Interpretación de Datos
 No toda la información que se vaya a utilizar se encontrará procesada, será

necesario realizar un proceso de adecuación de los datos para nuestro proyecto.
Definiendo Roles
 Quienes son los personajes que harán uso de los resultados, quienes conforman
los orígenes de los datos, quienes se encargarán de transformar o procesar los
datos.
 Se recomienda definir una matriz con todos los roles considerador en el proyecto,
desde el patrocinador, el gerente de proyecto, clientes, usuarios finales, etc.

Definiendo el Grupo de Trabajo

Un grupo de proyecto de Data Warehouse, puede contar con las siguientes personas,
dependiendo de la amplitud y complejidad del proyecto: Administrador del Proyecto,
Arquitecto de Soluciones, Modelador de Datos, Administrador de Base de Datos,
Especialista en Infraestructura, Desarrollador para ETL, Usuarios y Analistas del
Negocio, Personal de Pruebas y Administradores de Datos.
Estimando el Costo del Proyecto
La percepción de valor de una solución de BI puede ser determinada en diferentes

ámbitos del negocio, como por ejemplo mejorar el flujo de información del negocio,
generar utilidad directa e indirecta, reducir costos, soportar y dar confiabilidad a
decisiones estratégicas, así como una infinidad de escenarios más.
La pregunta obligada es ¿Realmente se puede obtener el ROI desde la definición del

proyecto?, definitivamente es imposible determinar un ROI cercano a la realidad,
porque sencillamente estamos midiendo escenarios que no conocemos, por decir un
ejemplo, desde la percepción del proyecto podríamos contestar lo siguiente ¿Cuánto
nos ahorraríamos de gastos? ó ¿Qué porcentaje mejorarían nuestras ventas? ¿Cuánto
crecerá nuestra utilidad?
En la vida real suceden diferentes escenarios, un escenario es que algunas empresas

con solo dar visión de la información y tomar una decisión simple y a la vez fácil desde
una implementación adecuada de BI que consistiría comprar más producto en cierto
periodo o dejar de comprar cierto producto, el valor en dinero de la decisión habría
pagado “n” veces el costo económico de la solución. Otro escenario de la vida real sería
el siguiente, se compran 100 licencias para acceso a una herramienta de BI donde solo
es utilizada por 5 usuarios de los 100 posibles, ¿Esto estaba considerado para
determinar el ROI?, definitivamente no.

Documentando el Plan de Solución
Se deben de listar todos los incidentes en la medida en que se van identificando a lo

largo del proyecto, con un Identificador, descripción, clasificación, probabilidad
ocurrencia, grado de impacto, plan de mitigación, responsable, fecha límite, estatus
actual, plan de contingencia y el criterio que debe cumplir para considerarse como una
acción cerrada.
Implementación
La percepción de valor de una solución de BI puede ser determinada en diferentes

ámbitos del negocio, como por ejemplo mejorar el flujo de información del negocio,
generar utilidad directa e indirecta, reducir costos, soportar y dar confiabilidad a
decisiones estratégicas, así como una infinidad de escenarios más.
Existen artículos de especialistas en BI que definen que la clave de tomar la decisión

de implementar una solución de BI consiste en determinar el ROI de la misma.

CAPÍTULO 3
 Diseñando el Data Mart
 Metodología Codd (Copo de Nieve)
 Metodología Kimball (Estrella)
 Analizando un Diseño OLTP Tradicional

D I S E Ñ A N D O D A T A M A R T
Un Data mart es una versión especial de almacén de datos (data warehouse). Son
subconjuntos de datos con el propósito de ayudar a que un área específica dentro del
negocio pueda tomar mejores decisiones. Los datos existentes en este contexto pueden
ser agrupados, explorados y propagados de múltiples formas para que diversos grupos
de usuarios realicen la explotación de los mismos de la forma más conveniente según
sus necesidades.
El Data mart es un sistema orientado a la consulta, en el que se producen procesos

batch de carga de datos (altas) con una frecuencia baja y conocida. Es consultado
mediante herramientas OLAP (On line Analytical Processing - Procesamiento Analítico
en Línea) que ofrecen una visión multidimensional de la información. Sobre estas bases
de datos se pueden construir EIS (Executive Information Systems, Sistemas de
Información para Directivos) y DSS (Decision Support Systems, Sistemas de Ayuda a la
toma de Decisiones).
Según la tendencia marcada por Inmon sobre los data warehouse, un data mart
dependiente es un subconjunto lógico (vista) o un subconjunto físico (extracto) de un
almacén de datos más grande, que se ha aislado por alguna de las siguientes razones:
Se necesita para un esquema o modelo de datos espacial (por ejemplo, para

reestructurar los datos para alguna herramienta OLAP).
Prestaciones: Para descargar el data mart a un ordenador independiente para mejorar

la eficiencia o para obviar las necesidades de gestionar todo el volumen del data
warehouse centralizado.
Seguridad: Para separar un subconjunto de datos de forma selectiva a los que queremos
permitir o restringir el acceso.
Conveniencia: la de poder pasar por alto las autorizaciones y requerimientos necesarios

para poder incorporar una nueva aplicación en el Data Warehouse principal de la
Empresa.
Demostración sobre el terreno: para demostrar la viabilidad y el potencial de una

aplicación antes de migrarla al Data Warehouse de la Empresa.

Política: Razones internas de la organización para hacer esta división o separación de

los datos del almacén de datos, por ejemplo:
Cuando se decide una estrategia para las TI (Tecnologías de la información) en

situaciones en las que un grupo de usuarios tiene más influencia, para determinar si se
financia dicha estrategia o descubrir si ésta no sería buena para el almacén de datos
centralizado.
Estrategia para los consumidores de los datos en situaciones en las que un equipo de
almacén de datos no está en condiciones de crear un almacén de datos utilizable.
Según la escuela Inmon de data warehouse, entre las pérdidas inherentes al uso de
data marts están la escalabilidad limitada, la duplicación de datos, la inconsistencia de
los datos con respecto a otros almacenes de información y la incapacidad para
aprovechar las fuentes de datos de la empresa. Así y todas estas herramientas son de
gran importancia.
Metodología Codd (Copo de Nieve)

En las bases de datos utilizadas en (data warehousing), un esquema en copo de nieve
es una estructura algo más compleja que el esquema en estrella. Se da cuando alguna
de las dimensiones se implementa con más de una tabla de datos. La finalidad es
normalizar las tablas y así reducir el espacio de almacenamiento al eliminar la
redundancia de datos; pero tiene la contrapartida de generar peores rendimientos al
tener que crear más tablas de dimensiones y más relaciones entre las tablas (JOINS) lo
que tiene un impacto directo sobre el rendimiento.

El único argumento a favor de los esquemas en copo de nieve es que al estar

normalizadas las tablas de dimensiones, se evita la redundancia de datos y con ello se
ahorra espacio. Pero si tenemos en cuenta que hoy en día, el espacio en disco no suele
ser un problema, y sí el rendimiento, se presenta con una mala opción en Data
warehouse, ya que el hecho de disponer de más de una tabla por cada dimensión de la
tabla de hechos implica tener que realizar código más complejo para realizar una
consulta que a su vez se ejecutará en un tiempo mayor, debido en parte al mayor
número de uniones (JOINS) que habrá que realizar.
Se puede usar un esquema de copo de nieve en un Data warehouse, aunque estos

sean realmente grandes y complejos, pero nunca en sistemas donde el tiempo de
respuesta sea un factor crítico para los usuarios.
Metodología Kimball (Estrella)

En las bases de datos usadas para data warehousing, un esquema en estrella es un
modelo de datos que tiene una tabla de hechos (o tabla fact) que contiene los datos
para el análisis, rodeada de las tablas de dimensiones. Este aspecto, de tabla de hechos
(o central) más grande rodeada de radios o tablas más pequeñas es lo que asemeja a
una estrella, dándole nombre a este tipo de construcciones.
Las tablas de dimensiones tendrán siempre una clave primaria simple, mientras que en
la tabla de hechos, la clave principal estará compuesta por las claves principales de las
tablas dimensionales.
Este esquema es ideal por su simplicidad y velocidad para ser usado en análisis
multidimensionales (OLAP, Datamarts, EIS,..). Permite acceder tanto a datos agregados
como de detalle.
El diseño de esquemas en estrella permite implementar la funcionalidad de una base de

datos multidimensional utilizando una clásica base de datos relacional (más extendidas
que las multidimensionales).

Otra razón para utilizar los esquemas en estrella es su simplicidad desde el punto de
vista del usuario final. Las consultas no son complicadas, ya que las condiciones y las
uniones (JOIN) necesarias sólo involucran a la tabla de hechos y a las de dimensiones,
no haciendo falta que se encadenen uniones y condiciones a dos o más niveles como
ocurriría en un esquema en copo de nieve. En la mayoría de los casos son preferibles
los de estrellas por su simplicidad respecto a los de copo de nieve por ser más fáciles
de manejar.
Finalmente, es la opción con mejor rendimiento y velocidad pues permite indexar las
dimensiones de forma individualizada sin que repercuta en el rendimiento de la base de
datos en su conjunto.
Analizando un diseño OLTP Tradicional

OLTP es la sigla en inglés de Procesamiento de Transacciones En Línea (OnLine
Transaction Processing) es un tipo de procesamiento que facilita y administra
aplicaciones transaccionales, usualmente para entrada de datos y recuperación y
procesamiento de transacciones (gestor transaccional). Los paquetes de software para
OLTP se basan en la arquitectura cliente-servidor ya que suelen ser utilizados por
empresas con una red informática distribuida.
El término puede parecer ambiguo, ya que puede entenderse "transacción" en el

contexto de las "transacciones computacionales" o de las "transacciones en bases de
datos". También podría entenderse en términos de transacciones de negocios o
comerciales. OLTP también se ha utilizado para referirse a la transformación en la que
el sistema responde de inmediato a las peticiones del usuario. Un cajero automático de

un banco es un ejemplo de una aplicación de procesamiento de transacciones

comerciales.
La tecnología OLTP se utiliza en innumerables aplicaciones, como en banca electrónica,

procesamiento de pedidos, comercio electrónico, supermercados o industria.
El procesamiento de transacciones en línea cada vez necesita más recursos para las
transacciones que se propagan por una red y que pueden integrar a más de una
empresa. Por esta razón, el software actual para sistemas OLTP utiliza procesamiento
cliente-servidor y software de intermediación (middleware) que permite a las
transacciones correr en diferentes plataformas en una red.
En grandes aplicaciones, la eficiencia del OLTP puede depender de lo sofisticado que

sea el software de gestión de transacciones (como CICS en plataformas IBM) o de que
tácticas de optimización se utilizan para facilitar la gran cantidad de actualizaciones
concurrentes que se pueden producir en una base de datos orientada a OLTP.
En los sistemas de bases de datos descentralizados más exigentes, los programas de

intermediación OLTP distribuyen el procesamiento de transacciones entre varios
ordenadores en una red. A menudo OLTP se integra en una arquitectura orientada a
servicios o en un servicio Web.
Tablas Normalizadas
 El proceso de normalización de bases de datos consiste en aplicar una serie de

reglas a las relaciones obtenidas tras el paso del modelo entidad-relación al
modelo relacional.
 Las bases de datos relacionales se normalizan para:
 Evitar la redundancia de los datos.
 Disminuir problemas de actualización de los datos en las tablas.
 Proteger la integridad de los datos.
 En el modelo relacional es frecuente llamar tabla a una relación, aunque para
que una tabla sea considerada como una relación tiene que cumplir con algunas
restricciones:
 Cada tabla debe tener su nombre único.
 No puede haber dos filas iguales. No se permiten los duplicados.
 Todos los datos en una columna deben ser del mismo tipo.
Tablas Relacionadas
 El modelo relacional para la gestión de una base de datos es un modelo de datos

basado en la lógica de predicados y en la teoría de conjuntos. Es el modelo más
utilizado en la actualidad para modelar problemas reales y administrar datos
dinámicamente. Tras ser postuladas sus bases en 1970 por Edgar Frank Codd,
de los laboratorios IBM en San José (California), no tardó en consolidarse como
un nuevo paradigma en los modelos de base de datos.
 En este modelo todos los datos son almacenados en relaciones, y como cada
relación es un conjunto de datos, el orden en el que éstos se almacenen no tiene
relevancia.
 Este modelo considera la base de datos como una colección de relaciones. De
manera simple, una relación representa una tabla que no es más que un conjunto

de filas, cada fila es un conjunto de campos y cada campo representa un valor

que interpretado describe el mundo real. Cada fila también se puede denominar
tupla o registro y a cada columna también se le puede llamar campo o atributo.
 Para manipular la información utilizamos un lenguaje relacional, actualmente se
cuenta con dos lenguajes formales el Álgebra relacional y el Cálculo relacional.
El Álgebra relacional permite describir la forma de realizar una consulta, en
cambio, el Cálculo relacional sólo indica lo que se desea devolver.

CAPÍTULO 4
 Medidas y Granularidad
 Tablas de Hecho
 Tablas de Dimensión

Analizando un diseño OLAP

Un cubo OLAP, OnLine Analytical Processing o procesamiento Analítico en Línea,
término acuñado por Edgar Frank Codd de EF Codd & Associates, encargado por Arbor
Software (en la actualidad Hyperion Solutions), es una base de datos multidimensional,
en la cual el almacenamiento físico de los datos se realiza en un vector multidimensional.
Los cubos OLAP se pueden considerar como una ampliación de las dos dimensiones
de una hoja de cálculo.
A menudo se pensaba que todo lo que los usuarios pueden querer de un sistema de
información se podría hacer de una base de datos relacional. No obstante Codd fue uno
de los precursores de las bases de datos relacionales, por lo que sus opiniones fueron
y son respetadas.
La propuesta de Codd consistía en realizar una disposición de los datos en vectores

para permitir un análisis rápido. Estos vectores son llamados cubos. Disponer los datos
en cubos evita una limitación de las bases de datos relacionales, que no son muy
adecuadas para el análisis instantáneo de grandes cantidades de datos. Las bases de
datos relacionales son más adecuados para registrar datos provenientes de
transacciones (conocido como OLTP o procesamiento de transacciones en línea).
Aunque existen muchas herramientas de generación de informes para bases de datos
relacionales, éstas son lentas cuando debe explorarse toda la base de datos.
Por ejemplo, una empresa podría analizar algunos datos financieros por producto, por
período, por ciudad, por tipo de ingresos y de gastos, y mediante la comparación de los
datos reales con un presupuesto. Estos parámetros en función de los cuales se analizan
los datos se conocen como dimensiones. Para acceder a los datos sólo es necesario
indexarlos a partir de los valores de las dimensiones o ejes.
El almacenar físicamente los datos de esta forma tiene sus pros y sus contras. Por
ejemplo, en estas bases de datos las consultas de selección son muy rápidas (de hecho,
casi instantáneas). Pero uno de los problemas más grandes de esta forma de

almacenamiento es que una vez poblada la base de datos ésta no puede recibir cambios
en su estructura. Para ello sería necesario rediseñar el cubo.
En un sistema OLAP puede haber más de tres dimensiones, por lo que a los cubos
OLAP también reciben el nombre de hipercubos. Las herramientas comerciales OLAP
tienen diferentes métodos de creación y vinculación de estos cubos o hipercubos.
Medidas
Las medidas más útiles para incluir en una tabla de hechos son los aditivos, es decir,
aquellas medidas que pueden ser sumadas como por ejemplo la cantidad de producto
vendido, los costes de producción o el dinero obtenido por las ventas; son medidas
numéricas que pueden calcularse con la suma de varias cantidades de la tabla. En
consecuencia, por lo general los hechos a almacenar en una tabla de hechos van a ser
casi siempre valores numéricos, enteros o reales.
Granularidad
Una característica importante que define a una tabla de hechos es el nivel de

granularidad de los datos que en ella se almacenan, entendiéndose por 'granularidad' el
nivel de detalle de dichos datos, es decir, la granularidad de la tabla de hechos
representa el nivel más atómico por el cual se definen los datos. Por ejemplo, no es lo
mismo contar el tiempo por horas (grano fino) que por semanas (grano grueso); o en el
caso de los productos, se puede considerar cada variante de un mismo artículo como
un producto (por ejemplo, en una empresa textil, cada talla y color de pantalón podría
ser un producto) o agrupar todos los artículos de una misma familia considerándolos
como un único producto (por ejemplo, el producto pantalón genérico).
Como se puede observar, 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ía
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.
Tabla de Hechos o Fact Table
Una tabla de hechos (o tabla fact) es la tabla central de un esquema dimensional (en
estrella o en copo de nieve) y contiene los valores de las medidas de negocio o dicho
de otra forma los indicadores de negocio. Cada medida se toma mediante la intersección
de las dimensiones que la definen, dichas dimensiones estarán reflejadas en sus
correspondientes tablas de dimensiones que rodearán la tabla de hechos y estarán
relacionadas con ella.
La pregunta clave para identificar si se trata de una tabla de hechos (fact) es ¿Qué
quiero medir?
Las tablas de hechos pueden contener un gran número de filas, a veces cientos de
millones de registros cuando contienen uno o más años de la historia de una gran
organización, esta cardinalidad estará acotada superiormente por la cardinalidad de las
tablas dimensionales, Por ejemplo, si se tiene una tabla de hechos "TH" de tres
dimensiones D1, D2 y D3, el número máximo de elementos que tendrá la tabla de
hechos TH será:
Card(TH) = Card(D1) x Card(D2) x Card(D3)
Donde 'Card(x)' es la cardinalidad de la tabla 'x'
Naturalmente, estas cardinalidades no son fijas, ya que, por ejemplo, si una de las
dimensiones se refiere a los clientes de la empresa, cada vez que se dé de alta un nuevo
cliente se estará aumentando la cardinalidad de la tabla de hechos. Una de las
dimensiones suele ser el tiempo, éste puede medirse de muy distintas formas (por
horas, días, semanas, ...), pero lo cierto es que transcurre continuamente, y para que el
sistema funcione se deben añadir registros periódicamente a la tabla de esta dimensión
(tabla de tiempos) y esto también produce un aumento de la cardinalidad de la tabla de
hechos, ésta es la principal causa de que las tablas de hechos lleguen a tener una
cantidad de registros del orden de millones de elementos.
Dimensiones
En un almacén de datos o un sistema OLAP, la construcción de Cubos OLAP requiere

de una tabla de hechos y varias tablas de dimensiones, éstas acompañan a la tabla de

hechos y determinan los parámetros (dimensiones) de los que dependen los hechos
registrados en la tabla de hechos.
Las tablas de dimensiones son elementos que contienen atributos (o campos) que se
utilizan para restringir y agrupar los datos almacenados en una tabla de hechos cuando
se realizan consultas sobre dicho datos en un entorno de almacén de datos o data mart.
Estos datos sobre dimensiones son parámetros de los que dependen otros datos que
serán objeto de estudio y análisis y que están contenidos en la tabla de hechos. Las
tablas de dimensiones ayudan a realizar ese estudio/análisis aportando información
sobre los datos de la tabla de hechos, por lo que puede decirse que en un cubo OLAP,
la tabla de hechos contiene los datos de interés y las tablas de dimensiones contienen
metadatos sobre dichos hechos.
Dimensión Tiempo
En cualquier Dataware house se pueden encontrar varios cubos con sus tablas de
hechos repletas de registros sobre alguna variable de interés para el negocio que debe
ser estudiada. Como ya se ha comentado, cada tabla de hechos estará rodeada de
varias tablas de dimensiones, según que parámetros sirvan mejor para realizar el
análisis de los hechos que se quieren estudiar. Un parámetro que casi con toda
probabilidad será común a todos los cubos es el tiempo, ya que lo habitual es almacenar
los hechos conforme van ocurriendo a lo largo del tiempo, obteniéndose así una serie
temporal de la variable a estudiar.
Dado que el tiempo es una dimensión presente en prácticamente cualquier cubo de un
sistema OLAP merece una atención especial. Al diseñar la dimensión tiempo (tanto para
un esquema en estrella como para un esquema en copo de nieve) hay que prestar
especial cuidado, ya que puede hacerse de varias maneras y no todas son igualmente
eficientes. La forma más común de diseñar esta tabla es poniendo como clave principal
(PK) de la tabla la fecha o fecha/hora (tabla de tiempos 1). Este diseño no es de los más
recomendables, ya que a la mayoría de los sistemas de gestión de bases de datos les
resulta más costoso hacer búsquedas sobre campos de tipo "date" o "datetime", estos
costes se reducen si el campo clave es de tipo entero, además, un dato entero siempre
ocupa menos espacio que un dato de tipo fecha (el campo clave se repetirá en millones
de registros en la tabla de hechos y eso puede ser mucho espacio), por lo que se
mejorará el diseño de la tabla de tiempos si se utiliza un campo "TiempoID" de tipo
entero como clave principal

A la hora de rellenar la tabla de tiempos, si se ha optado

por un campo de tipo entero para la clave, hay dos
opciones, la que quizá sea más inmediata consiste en
asignar valores numéricos consecutivos (1, 2, 3, 4, ...)
para los diferentes valores de fechas. La otra opción
consistiría en asignar valores numéricos del tipo
"yyyymmdd", es decir que los cuatro primeros dígitos
del valor del campo indican el año de la fecha, los dos
siguientes el mes y los dos últimos el día. Este segundo
modo aporta una cierta ventaja sobre el anterior, ya que
de esta forma se consigue que el dato numérico en sí,
aporte por si solo la información de a qué fecha se
refiere, es decir, si en la tabla de hechos encontramos
el valor 20040723, sabremos que se refiere al día 23 de
julio de 2004; en cambio, con el primer método,
podríamos encontrar valores como 8456456, para
saber a qué fecha se refiere este valor tendríamos que
hacer una consulta sobre la tabla de tiempos.
Además del campo clave TiempoID, la tabla de hechos

debe contener otros campos que también es importante
estudiar. Estos campos serían:
 Un campo "año".- Para contener valores como
'2002', 2003, '2004', ...
 Un campo "mes".- Aquí se pueden poner los
valores 'Enero', 'Febrero', ... (o de forma
abreviada: 'Ene', 'Feb', ...), esto no está mal,
pero se puede mejorar si el nombre del mes va acompañado con el año al que
pertenece, es decir '2004 Enero', '2004 Febrero', ... de esta forma se optimiza la
búsqueda de los valores de un mes en concreto, ya que con el primer método,
si se buscan los valores pertenecientes al mes de "Enero de 2003", toda esa
información está contenida en un sólo campo, el "mes", no haría falta consultar
también el campo año.
 Un campo "mesID".- Este campo tendría que ser de tipo entero y serviría para
almacenar valores del tipo 200601 (para '2006 Enero') o 200602 (para '2006
Febrero'), de esta forma es posible realizar ordenaciones y agrupaciones por
meses.
De forma análoga a como se ha hecho con el campo mes, se podrían añadir más
campos como "Época del año", "Trimestre", "Quincena", "Semana" de tipo texto para
poder visualizarlos, y sus análogos de tipo entero "Época del año_ID", "TrimestreID",
"QuincenaID", "SemanaID" para poder realizar agrupaciones y ordenaciones. En
general se puede añadir un campo por cada nivel de granularidad deseado.
Otro campo especial que se puede añadir es el "Día de la semana" ('lunes', 'martes', ...),
este campo se suele añadir para poder hacer estudios sobre el comportamiento de los
días de la semana en general (no del primer lunes del mes de enero de un año concreto,
este tipo de estudio no suele tener interés), por esta razón, este campo no necesita ir
acompañado del mes o del año como los campos anteriores. También se puede añadir
su campo dual "ID" de tipo entero para poder ordenar y agrupar si fuera necesario.
Con los añadidos descritos podríamos tener una "Tabla de tiempos". Esta sería válida
para un diseño en estrella, para un diseño en copo de nieve habría que desglosar la

tabla de tiempos en tantas tablas como niveles jerárquicos contenga. Obsérvese que
los campos de tipo "ID" son todos de tipo entero, ya que será sobre estos campos sobre
los que se realizarán la mayoría de las operaciones y estas se realizarán más
eficientemente sobre datos enteros.
Elaborando nuestro Cubo
En el explorador de soluciones, ubicamos los elementos necesarios para poder crear

nuestro Cubo, en este caso, iniciaremos en el mismo orden en que se aprecia en la
figura, desde el Origen de Datos (Data Sources) hasta las Dimensiones (Dimensions).
Procederemos a crear un Origen de datos, para ello hacemos clic derecho y

seleccionamos nuevo origen, apareciendo la siguiente figura, donde se colorará el
nombre del servidor, el nombre de la base de datos (datawarehouse) y también el
nombre del usuario y contraseña con el cual realizaremos la conexión.

Sabiendo de donde vamos a extraer los datos, crearemos una vista de origen de datos,
desde la cual se especificarán las dimensiones y hechos que utilizaremos para crear el
cubo, como se puede ver se inicializa el asistente para vistas.

Se recomienda primero seleccionar la tabla de hechos, sobre la cual giran las demás
tablas de dimensiones del datawarehouse.
Para mayor seguridad, seleccionamos la tabla de hechos y luego hacemos un clic sobre
el botón “Add Related Tables” para que se agreguen todas las tablas que se encuentren
relacionadas a dicha tabla de hechos,

Una vez seleccionadas las tablas, procederemos a guardar el proyecto otorgándole un

nombre alusivo a la información que permitirá mostrar.
Esta vista lucirá de la siguiente forma:

Una vez tengamos listo la vista, procederemos a crear el cubo, para ello haremos clic
derecho sobre el icono de Cubos y seleccionamos nuevo cubo.
Nos da la bienvenida al asistente para crear cubos.

Y se nos da a escoger el método para crear el cubo, en este caso seleccionaremos la

alternativa “utilizar tablas existentes”, de tal forma que podamos utilizar la vista
previamente creada.

A continuación escogemos la vista con la cual queremos trabajar, de la cual indicaremos

la tabla de hechos que será utilizada para extraer las medidas. Si hacemos clic en el
botón de sugerencias, se marcarán aquellas tablas que tengas atributos con valores
numéricos, entre ellas la tabla Fact.
Luego se mostrarán las medidas que se encuentren dentro de la tabla de hechos,

teniendo la posibilidad de poder seleccionar que medidas serán utilizadas en nuestro
cubo.
Damos a conocer las dimensiones.

Ahora procederemos a darle un nombre al cubo, se sugiere que tenga la misma

referencia que la vista que la ocasiona.
Se puede apreciar en la gráfica que las tablas de hechos se muestran en un color

amarillo (factvtaProducto) y las de dimensión en color azul (dmProducto y
dmCategoria). Es fácil también reconocer el tipo de esquema que se tiene creado, si
es copo de nieve o estrella.

Ahora procederemos a llenar el cubo con los datos provenientes del dataware house,
para ello hacemos clic en el botón de procesar, apareciendo una ventana similar a esta,
donde damos aceptar.
Desde esta ventana podremos dar a conocer algunas propiedades del cubo antes de su
llenado.

Procedemos a realizar la corrida, observándose la pantalla que muestra el progreso de

dicha operación.

Terminado el procesamiento, aparecerá una pantalla como la siguiente, desde donde

se podrán realizar pruebas de los datos que tiene contenidos el cubo.
Por ejemplo, podemos mejorar la presentación, considerando que nuestra dimensión

solo presenta las llaves, para ello, haremos clic derecho sobre la dimensión, le damos
abrir y tendremos a la mano esta pantalla desde la cual agregaremos más campos o
atributos a la dimensión que se utiliza.
Una vez agregados los campos, volvemos a procesar todo el cubo, le damos recargar y
actualizar los datos, de tal forma que podamos distinguir los cambios realizados.

Solo basta con arrastrar los campos a la sección de presentación de datos.

CAPÍTULO 5
 Planificación del ETL
 Planificando una solución SSIS
 Diseño del flujo de datos

P L A N I F I C A C I Ó N D E L E T L
 ETL (Extract Transform Load = Extraer, Transformar y Cargar) es la operación
que permite recuperar los datos desde una origen (puede ser desde cualquier
DBMS del mercado) hacia el datawarehouse (destino).
 Hay que tener bien en claro que existen un origen (source) y un destino
(destination) para todo ETL.
Identificación de fuentes y destinos de datos

 La Fuente, llamada también Origen, es donde se encuentran los datos que
vamos a necesitar para poder trabajar nuestro modelo de BI.
 Un proyecto de BI puede tener varios orígenes de datos, pudiendo ser estos de
diferentes fabricantes inclusive.
 Los datos del Origen pueden necesitar algún tipo de transformación antes de
llegar al DW o pueden pasar directamente, eso dependerá del análisis que se
haya realizado.
 El Destino siempre es el DW, salvo aquellos casos donde sea necesario realizar
acomodo de datos o transformaciones, pudiendo ser requerido tener un área de
trabajo denominado STAGE.


Evaluación de las fuentes de datos

 Una de las primeras tareas a realizar es determinar cómo se encuentran los
origines de datos. La integridad de estos es importante para poder obtener los
resultados esperados.
 En caso que tengamos información o datos “basura”, será necesario realizar una
limpieza de estos, para poder llevar solo aquellos que sean importantes. Si el
modelo presenta un gran porcentaje de datos erróneos será necesario que se
evalué una revisión desde la misma aplicación que los genera.
Identificación de requisitos
 Para iniciar nuestro proyecto es necesario contar con los permisos necesarios
para poder acceder a los “orígenes de datos”, vale decir, los usuarios de BD que
tengan privilegios de administrador o de lo contrario que sean propietarios de la
BD.
 El servidor de desarrollo debe tener una conectividad con los servidores de BD
que servirán de orígenes.
 Tener una idea clara de que datos son los necesarios para la extracción.

CAPÍTULO 6
 Planificando una solución SSIS
 Planificando Paquetes
 Diseño del flujo de control de los paquetes

P L A N I F I C A N D O U N A S O L U C I Ó N S S I S
 Empezamos creando un nuevo proyecto con el Visual Studio NET que viene
incorporado con el SQL Server.
El tipo de proyecto debe de ser “Integration Services Proyect”, es necesario también

indicar la ruta que tendrá, así como el nombre mismo del proyecto.

Planificación de paquetes y planificación de su

desarrollo
 Nuestro proyecto estará conformado por una serie de paquetes, los cuales harán
mención a los datos o tareas que serán requeridos.
 La cantidad de paquetes estará determinada por la cantidad de tablas que se
vayan a utilizar, esto es, cada tabla debería de tener su propio paquete.
 Como se podrá apreciar, nuestro proyecto está listo para crear los paquetes que
se requieran para el ETL.

Diseño del Flujo de control de los paquetes

Haciendo uso de la herramienta “Data Flow Task”, procedemos a crear un paquete, el
cual contendrá las acciones necesarias para poder cargas los datos de una tabla.
Una vez creado el paquete, hacemos clic derecho sobre él y seleccionamos “EDIT”,
para que se apertura una nueva ventana de trabajo.

Desde este punto vamos a poder crear los orígenes y destinos de nuestro ETL,
empezamos creando un componente de tipo “Source Asistent” para definir la base de
datos de origen.

Ahora damos a conocer el nombre del servidor al cual nos conectaremos para extraer
los datos, así mismo el nombre de la base de datos origen. Tener en cuenta que
podemos administrar varios orígenes de datos.
Para los ejemplos estamos utilizando usuarios con autenticación Windows.

Es recomendable hacer una prueba de conexión, para verificar que estamos realizando
correctamente el trabajo.

Una vez completado el proceso de creación de del objeto conexión, podremos configurar
el objeto de origen de datos. Tener en cuenta que el objeto conexión será reutilizado
cada vez que se quiera recuperar datos desde la base de datos a la cual tiene acceso.
Ahora, el objeto de origen de datos requiere saber de dónde vendrán los datos, para
ello podemos escoger entre acceder directamente a una tabla a o vista de la base de
datos o de lo contrario se puede insertar una sentencia de tipo SQL que indique los
datos requeridos.
Para este caso hemos seleccionado una tabla, pudiendo indicar que campos son los
que serán utilizados, basta con marcar el campo que será utilizado.

Como se puede observar, en la lista inferior solo se muestran los campos que están
siendo considerados para la extracción de datos.
Ahora crearemos un objeto de destino, pero nos pide crear primero un objeto de origen
de datos, en este caso seleccionaremos el servidor de destino, el que contiene nuestro
datawarehouse.

Como se puede observar en la lista de bases de datos disponibles, procedemos a

seleccionar el datawarehouse.
No olvidar siempre realizar sus pruebas de conexión de datos, para comprobar que el
trabajo se está realizando correctamente.


CAPÍTULO 7
 Diseño del flujo de datos
 Compresión del flujo de datos
 Diseño de las operaciones

D I S E Ñ O D E L F L U J O D E D A T O S
Ahora debemos de tener una vista que muestre a los objetos de origen y destino de
datos, sin embargo, el objeto de destino de datos se muestra con un símbolo de error,
esto porque este tipo de objeto depende su funcionamiento de un origen de datos.
Unimos ambos objetos, considerando un flujo de proceso, de esta manera

procederemos a configurar el objeto de destino de datos.

Ingresamos a configurar el objeto de destino de datos haciendo clic derecho sobre él,
luego seleccionamos “edit”, para que se muestre una pantalla donde se especificará
que tabla será la que reciba los datos del origen.
Una vez seleccionada la tabla de destino, procederemos a emparentar los campos del
origen de datos con los del destino, debiéndose tener una vista como la que sigue.
Completado el emparejamiento de campos, deberíamos de tener una vista como la

siguiente, sin ningún tipo de mensaje de error entre los objetos, de ser así, tendremos

que verificar la conectividad hacia las conexiones o podría ser un problema con los tipos
de datos de los campos que se están utilizando.
Terminada la configuración de los objetos de origen y destino de datos, regresamos a

la pantalla de flujo de paquetes, desde donde podremos seguir agregando más
paquetes de tareas a realizar.
Comprensión del flujo de datos, y diseño de las

operaciones
Como vamos a realizar más pruebas de carga de datos, el volver a ejecutar la corrida
de carga de datos, nos devolvería un error de integridad de datos, puesto que las tablas
tendrían duplicidad de llaves, esto hace necesario que agreguemos un control que nos
permita borrar los contenidos de las tablas, para ello optaremos por el control “Execute
SQL Task”, el cual nos permitirá ejecutar una sentencia SQL con la cual eliminaremos
los datos de las tablas involucradas.

Dentro de las propiedades del control, procederemos a indicar hacia que servidor y base
de datos nos conectaremos.
Con la propiedad Connection Type podemos indicar que tipo de conexión es la

utilizaremos para apuntar al servidor de base de datos.

Luego, desde la propiedad connection, seleccionaremos el objeto de base de datos

que utilizaremos para acceder a la base de datos.
Ahora ubicamos la propiedad SQLStatement, donde escribiremos la sentencia SQL.

Se abrirá una ventana donde digitaremos la sentencia SQL que nos permita borrar los
datos existentes en las tablas de nuestro datawarehouse.
En caso se tuvieran varias sentencias a ejecutar, se terminará la sentencia con un punto

y coma, no utilizar la palabra go como lo hacían desde el Management del SQL Server,
puesto que les devolvería un mensaje de error.

Para este caso es importante iniciar el flujo con el control que nos permite borrar el
contenido de las tablas del datawarehouse.
Una vez completo el flujo de trabajo, procederemos a realizar la prueba del modelo, para
ello haremos clic sobre el botón de ejecutar o de lo contrario presionamos el botón F5
con lo cual se empezará la corrida del proyecto. Se espera que todos los controles
muestren un icono de color verde que indica que todo salió correctamente.

De esta manera se completó el proceso de ETL, con la debida carga de datos en el

datawarehouse.


Í N D I C E
Capítulo 1 .................................................................................................................... 1
Inteligencia de Negocios ........................................................................................ 2
Que es Inteligencia de Negocios ........................................................................... 2
Como apoya Inteligencia de Negocios al flujo de información de la empresa ........ 3
Quien necesita soluciones de Inteligencia de Negocios ........................................ 3
Gestión de la Información con Inteligencia de Negocios .................................... 5
El escenario competitivo de hoy ............................................................................ 5
Necesidad de Inteligencia de Negocios ................................................................. 5
El valor de Inteligencia de Negocios ...................................................................... 6
Instalación de la Plataforma de Inteligencia de Negocios con Microsoft ........... 7
Windows Server .................................................................................................... 7
SQL Server ........................................................................................................... 7
Introducción a una Solución de Inteligencia de Negocios. ................................. 8
Creando Modelo de Data Mart con SQL Server .................................................... 8
Creando ETL con SQL Server ............................................................................... 8
Creando Cubo con Analysis Services.................................................................. 10
Capítulo 2 .................................................................................................................. 11
Planeando Solución de Inteligencia de Negocios .............................................. 12
Pasos del Proceso .............................................................................................. 13
Entrevista......................................................................................................... 13
Documentación Requerida .............................................................................. 13
Ubicación e Interpretación de Datos ................................................................ 13
Definiendo Roles ............................................................................................. 13
Definiendo el Grupo de Trabajo........................................................................... 14
Estimando el Costo del Proyecto ..................................................................... 14
Documentando el Plan de Solución ................................................................. 15
Implementación ............................................................................................... 15
Diseñando Data Mart ............................................................................................ 17
Metodología Codd (Copo de Nieve) .................................................................... 18
Metodología Kimball (Estrella) ............................................................................. 19
Analizando un diseño OLTP Tradicional .............................................................. 20
Tablas Normalizadas ....................................................................................... 21
Tablas Relacionadas ....................................................................................... 21
Analizando un diseño OLAP ................................................................................ 24
Medidas ........................................................................................................... 25
Granularidad .................................................................................................... 25
Tabla de Hechos o Fact Table ......................................................................... 26
Dimensiones .................................................................................................... 26
Dimensión Tiempo ........................................................................................... 27
Elaborando nuestro Cubo ................................................................................ 29
Capítulo 3 .................................................................................................................. 41
Planificación del ETL ............................................................................................ 42
Identificación de fuentes y destinos de datos ...................................................... 42
Evaluación de las fuentes de datos ..................................................................... 44
Identificación de requisitos .................................................................................. 44
Planificando una solución SSIS........................................................................... 46

Planificación de paquetes y planificación de su desarrollo ...................................47

Diseño del Flujo de control de los paquetes .........................................................48
Diseño del flujo de datos ......................................................................................57
Comprensión del flujo de datos, y diseño de las operaciones ..............................59

Implementación de Inteligencia de Negocios con SQL Server 2014

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Implementación de Inteligencia de Negocios con SQL Server 2014

Cargado por

Copyright:

Formatos disponibles

Facultad de Ingeniería Industrial y de Sistemas

Business Intelligence con SQL Server 2014 - Implementación danielramos@dba.pe Pág. 1

Que es Inteligencia de Negocios

Desde un punto de vista más pragmático, y asociándolo directamente con las

La inteligencia de negocio actúa como un factor estratégico para una empresa u

Para definir BI de otra forma, utilizaremos la definición de la consultora Gartner:

El proceso de Business Intelligence incluye la comunicación de los descubrimientos y

Las áreas incluyen clientes, proveedores, productos, servicios y competidores.”

Pág. 2 danielramos@dba.pe Business Intelligence con SQL Server 2014 - Implementación

Como apoya Inteligencia de Negocios al flujo de

Quien necesita soluciones de Inteligencia de Negocios

Para realizar un diagnóstico instantáneo de su empresa, sólo tiene que responder al

 ¿Tiene problemas para crear una visión clara de toda su organización?

 ¿Sabe si está perdiendo cuota de mercado con respecto a su competencia?

 ¿Ha perdido oportunidades de negocio por recibir información atrasada?

 ¿Dedica horas extras a analizar documentos e informes?

Business Intelligence con SQL Server 2014 - Implementación danielramos@dba.pe Pág. 3

 ¿Tiene informes de varios sistemas operacionales que no concuerdan?

 ¿Sabe con certeza si su gente está alcanzando los objetivos planificados?

Si al menos la mitad de las respuestas han sido afirmativas, su empresa puede

Pág. 4 danielramos@dba.pe Business Intelligence con SQL Server 2014 - Implementación

El escenario competitivo de hoy

Necesidad de Inteligencia de Negocios

Business Intelligence con SQL Server 2014 - Implementación danielramos@dba.pe Pág. 5

El valor de Inteligencia de Negocios

Imaginemos una situación hipotética: se ha convocado una reunión para analizar la

Pág. 6 danielramos@dba.pe Business Intelligence con SQL Server 2014 - Implementación

La versión de Windows Server que se puede utilizar es la 2008 o la 2012.

Cualquier duda sobre la instalación de este producto, consultar el manual de SQL

Business Intelligence con SQL Server 2014 - Implementación danielramos@dba.pe Pág. 7

Creando Modelo de Data Mart con SQL Server

Creando ETL con SQL Server

Pág. 8 danielramos@dba.pe Business Intelligence con SQL Server 2014 - Implementación

Como se puede observar en el siguiente gráfico, la definición del circuito estará

Business Intelligence con SQL Server 2014 - Implementación danielramos@dba.pe Pág. 9

Creando Cubo con Analysis Services

 Data Sources, con el cual nos conectamos al

Pág. 10 danielramos@dba.pe Business Intelligence con SQL Server 2014 - Implementación

Business Intelligence con SQL Server 2014 - Implementación danielramos@dba.pe Pág. 11

La misión de la inteligencia de negocios es proveer una única vista del negocio y

La inteligencia de negocios tiene su mayor impacto en el negocio en la medida que se

Esta alineación se logra diseñando y ejecutando el programa de inteligencia de

Más aún, un enfoque de mayor alcance organizacional y estratégico es la

BI Analytics ofrece sus servicios en la conformación de un programa de gobierno de los

Pág. 12 danielramos@dba.pe Business Intelligence con SQL Server 2014 - Implementación

Pasos del Proceso

 Es importante poder entrevistar a todas las personas necesarias que nos

 Toda aquella información que nos permita conocer la forma de recolección y

Ubicación e Interpretación de Datos

 No toda la información que se vaya a utilizar se encontrará procesada, será

Business Intelligence con SQL Server 2014 - Implementación danielramos@dba.pe Pág. 13

Definiendo el Grupo de Trabajo

Estimando el Costo del Proyecto

La percepción de valor de una solución de BI puede ser determinada en diferentes

La pregunta obligada es ¿Realmente se puede obtener el ROI desde la definición del

En la vida real suceden diferentes escenarios, un escenario es que algunas empresas

Pág. 14 danielramos@dba.pe Business Intelligence con SQL Server 2014 - Implementación

Documentando el Plan de Solución

Se deben de listar todos los incidentes en la medida en que se van identificando a lo

La percepción de valor de una solución de BI puede ser determinada en diferentes

Existen artículos de especialistas en BI que definen que la clave de tomar la decisión

Business Intelligence con SQL Server 2014 - Implementación danielramos@dba.pe Pág. 15