Trabajo GBI6501

Instituto Profesional
DuocUC – Sede Puente Alto.

Av. Concha y Toro 1340
Guía de Trabajo GBI
I) Desarrolle los siguientes pasos, según se indica en el documento
1. Nuestro cliente es una empresa de tamaño medio, que produce bienes

deportivos y accesorios, recientemente agregó ropa deportiva. Sus clientes
son grandes empresas de retail alrededor del mundo.
2. La información disponible está restringida por la funcionalidad del actual ERP

que maneja la empresa, lo que dificulta al usuario final acceder a información
operacional. Construir reportes para responder a preguntas de negocio es un
proceso muy lento y costoso, y la promesa de “reportes para el usuario final”
nunca se cumplió porque la empresa incluye en sus procesos muchos
sistemas de información, donde en cada sistema la información está
ingresada de forma cruzada en una gran cantidad de tablas, lo que requiere
de un alto conocimiento para responder preguntas simples de negocios.
3. Se tienen los siguientes problemas:

a) El fabricante está disminuyendo su competitividad, porque sus procesos
de negocio no resisten el cambio. Iniciativas como mejoras en los tiempos
de envío de productos y un entendimiento real del impacto de descuentos
a clientes complejos, es información intensiva, y muchas veces casi
imposible de alcanzar a través del negocio mediante una vía efectiva de
tiempo y costos.
b) Las TI de la empresa están viendo dificultada la posibilidad de entregar
información necesaria para mantener vivos los procesos de negocio frente
al cambio del entorno de negocios, y con la complejidad de los sistemas
ERP actuales, está tomando grandes cantidades de tiempo el entregarla.
Es muy costoso responder una consulta simple con este tipo de
estructuras.
Página 1 de 28 GESTION DE NEGOCIOS CON BUSINESS INTELLIGENCE
Marcelo Magaña
c) El uso de los sistemas ERP para retornar la información está afectando

negativamente el tiempo de respuesta transaccional de los sistemas
durante las horas peak de uso.
4. Usted construirá un DataWarehouse que consolide la información de los

diferentes sistemas ERP y de otras fuentes de datos para habilitar nuevos
tipos de análisis y reducir los costos y complejidad al retornar información.
Con nuestro enfoque de negocio basado en el valor, nos centraremos en la
creación de la funcionalidad necesaria para apoyar los objetivos de negocio de
mayor prioridad mientras que proporciona una plataforma para futuras mejoras.
5. Requerimientos del Negocio:

a) Informes de Ventas y seguimiento del rendimiento. La empresa necesita
el acceso oportuno y flexible a la información de ventas, tales como unidades
vendidas y los ingresos, incluyendo la capacidad de comprender el
rendimiento de las ventas por territorio, por producto y por cliente. En última
instancia, el objetivo es realizar un seguimiento de las ventas reales
obtenidos en relación con los objetivos para cada territorio de ventas.
b) Rentabilidad. Un conductor clave del negocio es que la solución debe incluir
suficiente información para permitir el análisis de rentabilidad. Esto incluirá
información como la fabricación y los gastos de envío y los descuentos
ofrecidos a los clientes. Esto permitirá a la empresa a entender la rentabilidad
de las líneas de producto, así como los tipos de clientes y optimizar la mezcla
de productos y clientes.
6. Arquitectura de Alto Nivel

a) El componente principal de nuestra solución es una base de datos de
almacén de datos que recibe información de los sistemas de origen, como se
muestra en la Figura de la página siguiente.

Marcelo Magaña
7. Modelo de Datos
a) El objetivo principal del modelo de datos dimensional es para producir un
modelo simple y consistente que se expresa en el lenguaje de los propios
usuarios y les permitirá acceder fácilmente a la información. Un desafío
común en la construcción de soluciones de BI es que a menudo hay muchas
áreas en el negocio que tienen información interesante, que realmente
necesita para resistir a tratar de producir un modelo de datos inicial que cubre
en todo el asunto. El principio clave de nuestro enfoque es que debe definir
las áreas que se centrará en ofrecer de manera que se alinean con los
objetivos y pueden ofrecer un valor empresarial real (algo que ha sido escaso
en muchos grandes proyectos de almacenamiento de datos).
b) En que proceso nos centraremos?
Los requisitos de negocio describen nuestra área de interés como las ventas
y los informes de rentabilidad. Vamos a entregar el modelo de datos para
apoyar estas necesidades, pero el diseño de las dimensiones para que
puedan convertirse en "una única versión de la verdad", es decir el tiempo
utilizado en otras áreas del negocio, tales como el análisis de la programación
de la fabricación o el análisis de la pérdida.
Como resultado, la definición de los procesos de negocio exacta que tenemos

resulta en un modelo que es un poco complicado. Para controlar la
presentación de informes de ventas y rentabilidad, lo que necesitamos saber

Marcelo Magaña
la información de la fabricación (lo que es el costo real de los productos

manufacturados), pedidos y facturación (¿cuánto se cobra este cliente
teniendo en cuenta los descuentos y demás condiciones del contrato), y la
entrega ( hizo que la mercancía llegue a tiempo y en buenas
condiciones). Este dato es casi seguro que almacenan en tablas diferentes en
los sistemas de transacción, y de hecho puede estar en sistemas separados
por completo.
c) Que nivel de detalle necesitamos?
Ahora que hemos identificado los procesos de negocio envíos, la siguiente
pregunta que nos enfrentamos es el grano de la información
requerida. ¿Necesitamos los totales diarios de todos los envíos para el día, o
serían suficientes saldos mensuales? ¿Es necesario saber cuales son los
productos involucrados, o podemos resumir la información por categorías?
En cierto modo, esta cuestión de modelado de datos de granularidad es el

más fácil de resolver porque la respuesta es siempre la misma: Usted debe
tratar de utilizar siempre el nivel más detallado de la información que está
disponible. En el ejemplo de los envíos, tenemos que guardar un registro para
cada partida individual fábrica, incluidos el cliente que fue enviado a, el
producto de la UPC, la cantidad enviada, y el resto de la información que
podemos encontrar en esta área.
En los malos viejos tiempos antes de la tecnología se encontró con nuestras

ambiciones de BI, un montón de compromisos necesarios para tratar de evitar
grandes volúmenes de datos, que por lo general participan resumen de los
datos. La falta de información conduce a todo tipo de problemas en el ejemplo
ALMACENES datos, si guardamos los envíos resumen por grupos de
productos, ¿cómo puedo saber si los productos amarillas son más populares
que los verdes? Necesitamos la información de detalle del producto a nivel de
darse cuenta de eso. Hoy en día, hardware moderno y SQL Server 2005
Marcelo Magaña
fácilmente apoyo a la información detallada a nivel sin un tratamiento especial

en todo menos en el más exigente de las aplicaciones.
d) No mezclar granularidades en la Tabla Fact
Esta es probablemente la lección más importante de modelado tridimensional
que podemos compartir: una sola tabla de hechos que nunca hay que tomar
medidas en los diferentes niveles de granularidad. Esto suena como fácil de
lograr, pero algunos errores comunes pueden aparecer, por lo general
relacionados con la información presupuestaria o previsiones. Por ejemplo,
los usuarios de negocios a menudo se desea comparar la medida real (como
la cantidad real enviada) con una previsión de presupuesto o de la medida
(como la cantidad del presupuesto). Los presupuestos son por lo general
producidos en un mayor nivel de granularidad (por ejemplo, previsto de
ventas mensuales por grupo de productos), y por lo tanto nunca debe ser
puesto en la misma tabla de hechos que almacena las transacciones de nivel
de detalle. Si usted encuentra las medidas en los diferentes niveles de
granularidad, debe crear una tabla de hechos separados en el nivel
adecuado.
e) Cuales son las maneras de mirar la información?
El corazón del enfoque tridimensional es proporcionar información a los
usuarios de las maneras que les gustaría verlo. Una de las mejores maneras
de comenzar es identificar las dimensiones a tener en cuenta cada vez que
alguien dice la palabra “Por”. Por ejemplo, tenemos que ver las ventas por
planta de fabricación, y tenemos que mirar a las entregas por el método que
se enviaron para ver cuál es el método más rentable. Cada uno de estos
"por’s" es un candidato para una dimensión.
De las entrevistas con los usuarios de negocios, podemos hasta ahora añadir
dos dimensiones en nuestro modelo de datos, como se muestra en la Figura
siguiente: Planta, que identifica si el producto en un envío ha sido fabricado y

Marcelo Magaña
enviado, y método de envío, que indica el método utilizado para enviar el

producto.
I. Información de Productos
Una de las medidas principales en este almacén de datos contiene la
información del producto. Los productos pueden ser agrupadas en
subcategorías y categorías, y cada registro del producto puede contener
muchos atributos descriptivos que son útiles para la comprensión de las
ventas y la rentabilidad, como el color o el tamaño. Para que sea fácil de
cargar la información del producto y mejorar la eficiencia de las consultas
se utiliza para cargar el cubo, vamos a "copo de nieve", la dimensión y
crear tres mesas separadas, como se muestra en la Figura siguiente. Este
es el primer ejemplo del proceso de diseño de toma de decisiones, es
decir, cuando tenemos una tabla de dimensiones, con una jerarquía obvia,
podemos renormalizar o la dimensión de copo de nieve en una tabla
separada para cada nivel en la jerarquía .

Marcelo Magaña
Tenga en cuenta que cada tabla de dimensiones de copo de nieve todavía

sigue la regla de claves suplentes, que es que todas las claves principales
utilizados en un almacén de datos son claves suplentes y estas son las
claves sólo se utiliza para describir las relaciones entre las tablas de
almacenamiento de datos. En el caso de la tabla Product Subcategoría, se
puede ver que se ha utilizado el ProductCategoryKey para la relación con
la tabla de categoría de producto.
El fabricante de nuestro ejemplo tiene un tema interesante con

Productstheir negocio original fue la fabricación de artículos deportivos y
equipo relacionado, pero hace varios años que adquirieron otra empresa
con varias plantas que fabrican prendas de vestir relacionadas con los
deportes. Las dos divisiones de la compañía tienen sistemas ERP y líneas
de productos totalmente distintos. En un almacén de datos, queremos una
dimensión de producto único que es la única versión de la verdad.

Marcelo Magaña
A pesar de que los dos sistemas ERP pueden tener diferentes formas de
almacenar la información del producto y tendremos que realizar algunos
ejercicios de calistenia en la extracción, transformación y carga (ETL),
tenemos que conciliar estas diferencias para crear una dimensión de
producto único. El diseño que tenemos que evitar es que tiene dos
dimensiones del producto por separado que se asignan de nuevo a los
sistemas de origen, de lo contrario, será difícil para los usuarios para
incluir toda la información disponible en sus análisis.
II. Información de Clientes

La siguiente área de interés en nuestro modelo de datos de clientes. El
fabricante no vende directamente a los consumidores sino a los
minoristas, por lo que cada registro de cliente contiene información sobre
una empresa que hace negocios con el fabricante. Además de los
atributos tales como tipo de cliente (como minorista o distribuidor), una de
las fuentes más importantes de los atributos de los clientes es la
información geográfica.
Cada cliente se encuentra físicamente en una dirección, y se puede ver

cómo los usuarios considera que sería útil para poder agrupar los datos
por el Estado del cliente o provincia, o incluso navegar por las distintas
nivel de la ciudad. Además de esta naturales "geográfica" jerarquía, la
mayoría de las empresas también dividir las zonas geográficas en las
"zonas de venta." Estos territorios de ventas no se pueden traducir
perfectamente a las estructuras naturales de carácter geográfico, como
estado o provincia, ya que las normas de una empresa que rigen las
ciudades o la caída de clientes en el que los territorios de ventas puede
ser compleja o arbitrarias. Así que, a veces los usuarios finales se quiere
ver la información agrupada por la geografía física y, a veces agrupados
Marcelo Magaña
por zonas de venta.
En nuestro modelo de datos, vamos a extraer la información física

geográfica de los registros de los clientes y pasar una dimensión
Geografía, que tendrá un registro por cada Código Postal. Este registro
contendrá toda la dimensión de la información geográfica natural, como el
nombre del estado o provincia, y cada registro de cliente tendrá una
columna GeographyKey que contiene la clave sustituta del
correspondiente registro de Geografía. También vamos a crear una
dimensión de venta por separado territorio, y ampliar la dimensión de
Geografía, para que cada registro se refiere a un territorio de ventas en
particular, como se muestra en la Figura siguiente.

Marcelo Magaña
III.Información de Tiempo
Por lejos, la forma más común de ver la información en los almacenes de
datos es el análisis de la información en diferentes períodos de
tiempo. Usuario que desee ver los envíos del mes en curso, o los envíos
del año hasta la fecha, o comparar el período actual con el mismo período
del año pasado. Cada transacción de embarque tiene una o más fechas
asociadas con ella (como la fecha de pedido y envía la fecha), y tenemos
que permitir que estas fechas que se utiliza para agrupar los envíos
juntos.
Lo primero que tenemos que determinar es el nivel de detalle necesario

para nuestra tabla de hechos. El hecho de envíos incluye la fecha efectiva
de la transacción, por lo que necesitamos información del día a nivel no
sólo los resúmenes semanales o mensuales.
Porque la mayoría de las aplicaciones modernas incluyen extensas

funciones para la interpretación de los campos de fecha, podría parecer
que no es necesario crear una tabla de dimensiones reales de
tiempo. Como resultado, una tabla física que contiene un registro para
cada día, como se muestra en la Figura que sigue, es muy útil. No sólo
podemos incluir los atributos manifiesta todos los días, como el nombre
del día o del año, también puede ser creativo en proporcionar columnas
analíticas. Por ejemplo, podríamos incluir un indicador que muestra cuáles
son los días festivos para que los usuarios pueden seleccionar los días
para el análisis especial. Cuando tenemos un montón de atributos
descriptivos en la tabla, podemos utilizar las capacidades analíticas de

Marcelo Magaña
Analysis Services para proporcionar la capacidad de seleccionar los

rangos complicados como el año hasta la fecha.
Sugerencia: No incluya registros por hora o minuto

Si resultó ser útil conocer el tiempo real que una operación se produjo no
sólo el día, usted podría pensar que sólo tenemos que agregar
información más detallada a la tabla de dimensión de tiempo. Esto implica
una serie de problemas; (Almacenar registros a nivel minutos significaría
1.440 registros por día) no sólo este aumento del tamaño de la dimensión,
pero desde un punto de vista analítico, no es muy útil.
Usuarios más probable es que desea seleccionar un rango de fechas y

luego ver cómo las transacciones variado en diferentes momentos del
día. La mejor manera de apoyar esta es salir de la dimensión de tiempo a
nivel de días (Fecha probable nombre para mayor claridad) y crear una
dimensión separada de hora del día. Este marco debería incluir sólo un

Marcelo Magaña
registro por cada período de tiempo, como un total de 1.440 registros de

un minuto de tiempo a nivel de la dimensión día.
La otra característica útil que le puede proporcionar en una dimensión de

tiempo es el apoyo a múltiples formas de agrupación de fechas. Además
de buscar en una jerarquía de calendario naturales como el año o el mes,
la mayoría de las empresas desean tener la capacidad para ver los
períodos fiscales. Podemos acomodar esto incluyendo el año fiscal (que
por lo general comienza en un día diferente en el calendario natural) y el
mes fiscal en todos los registros al día, además de con el año calendario
estándar y mes. Esto también podría ampliarse para apoyar los
calendarios de producción, que consisten en 13 períodos de exactamente
el mismo tamaño que se compone de cuatro semanas cada uno.
Ahora que hemos identificado las diferentes maneras en que los usuarios
quieren ver la información, podemos pasar a nuestra pregunta de
modelado siguiente: ¿Qué números que el usuario desea analizar?
IV. Qué estamos midiendo?

Toda la información que queremos analizar, tales como los importes de
ventas, costos, o descuentos, que terminan en nuestra tabla de
hechos. Ahora que hemos identificado el grano de la tabla de hechos y
diseñado las dimensiones que va a utilizar, podemos pasar a la creación
de una lista de medidas numéricas de la tabla. En este punto del proceso
de diseño, la tabla de hechos se parece al Figura de más abajo.

Marcelo Magaña
Sugerencia: la importancia de aclarar los términos.

La mayoría de los modeladores de datos y encuentra desde el principio
que tratamos de hacer el modelado de datos, sin un buen conocimiento
del negocio subyacente es una empresa arriesgada. La gente a menudo
tienden a usar términos diferentes para el mismo concepto en función de
su área específica de la empresa, o usar los mismos términos para
conceptos muy diferentes en diferentes áreas de negocio. Es importante
reconocer esto y tener un cuidado especial para aclarar los términos,
aunque suenen como los conceptos de sentido común.
En última instancia, la fuente de todas las medidas en una tabla de hechos

será una tabla de transacciones en los sistemas ERP, pero sería un error
para iniciar a partir del esquema de ERP para identificar las
medidas. Según lo descrito previamente, en línea de procesamiento de
transacciones (OLTP) han normalización como motor principal de sus
Marcelo Magaña
diseños, mientras que mucha de la información en los almacenes de datos

se deriva. Un mejor enfoque es partir de las preguntas de negocios que
los usuarios necesitan para responder y luego tratar de construir una lista
de medidas que serán necesarias para proporcionar las respuestas. Parte
de esta información podría llegar a no estar disponible en los sistemas
ERP, pero al menos estas cuestiones puede ser identificado con el equipo
de ERP.
Por ejemplo, una medida candidato obvio es la cantidad del elemento

producto que el cliente pidió, pero igualmente importante para el análisis
es una medida que describe la cantidad real que fue entregado, teniendo
en cuenta las roturas o errores en el proceso de envío. Podemos añadir
tanto Cantidad ordenada, así como medidas de cantidad entregada a la
tabla de hechos. Los requisitos de negocio también nos lleva a agregar
otras columnas numéricas para apoyar el análisis de rentabilidad, como
los descuentos y los costes de fabricación.
V. Unidades de medida numéricas que no se pueden sumar.

Todas las medidas que hemos visto hasta ahora son totalmente aditivos,
es decir, si estamos buscando a un total de grupo de productos para el
último año las transacciones de un solo cliente en una semana, todo lo
que tenemos que hacer es resumir los números en la tabla de hechos
para llegar a la respuesta correcta. No todos los números son tan
serviciales, sin embargo, por ejemplo, mientras que la cantidad de
producto vendido en un registro de embarque es aditivo, el precio por
unidad no lo es. Si usted se imagina qué pasaría si nos fijamos en total un
año de todos los precios unitarios en la tabla de envíos, se puede ver que
esto no produciría una medida sensata. En el caso de los precios unitarios
que pueden aumentar o disminuir con el tiempo, y otro "tipo de" tipos de
medidas, la forma habitual de mirar a la información es a través de un
Marcelo Magaña
promedio durante el período de tiempo que está consultando.
La misma lógica se aplica generalmente para "equilibrar" los tipos de

medidas, tales como los saldos de inventario, ya sea en el saldo promedio
de la última equilibrio en el periodo de tiempo seleccionado es mucho más
significativo que un total. Estas medidas se conocen como parte de
aditivos o semi-aditivo, porque se puede resumir en las dimensiones como
cliente o producto, pero no a través de otras dimensiones, tales como la
dimensión de tiempo.
A menudo es posible transformar la "tasa" medidas en medidas totalmente

aditivo sólo multiplicando por la medida correspondiente, tales como la
cantidad. Esto producirá una medida completamente aditiva como
ingresos en lugar de una medida de suma parcial como Unitario. Si desea
incluir en realidad una medida de suma parcial, sólo tiene que agregar la
columna numérica sobre la tabla de hechos. Los cubos de Analysis
Services se pueden configurar de modo que el cálculo de resumen
adecuado se realiza de las medidas de suma parcial.
VI. Manejo de relaciones complejas con Dimensiones

La mayoría de las relaciones entre tablas de dimensiones y la tabla de
hechos son simples y fáciles de modelar. Por ejemplo, cada envío tiene un
método de envío, así que sólo podemos agregar la ShipMethodKey a la
tabla de hechos. No todas las dimensiones son tan fáciles de manejar, sin
embargo, el cliente y el tiempo dimensiones de la solución de fabricación
tienen una relación más compleja con la tabla de hechos.
Cada envío que hacemos es enviado a un cliente específico, por lo que

sólo puede agregar una columna CustomerKey a la tabla de hechos. Sin
embargo, a causa de las jerarquías corporativas complejas que el
Marcelo Magaña
fabricante tiene que hacer frente, el proyecto de ley para el envío puede
ser enviado a otra entidad corporativa (por ejemplo, una sociedad matriz)
que el cliente que recibió el envío. Es fácil encontrar los requerimientos del
negocio que requieren tanto de estos conceptos, tales como un análisis
financiero por parte del cliente de facturación y la logística o el análisis de
un envío por el cliente de envío. Para adaptarse a esto, podemos
simplemente añadir dos columnas ShippingCustomerKey y
BillingCustomerKey a la tabla de hechos y poblar en consecuencia.
La dimensión de tiempo tiene un requisito similar. Dependiendo del

análisis, los usuarios que desee ver los envíos por la fecha en que el
pedido, o la fecha en que fue enviado, o incluso para comparar la fecha en
realidad se incluye con la fecha en que el traslado se debió a tener
lugar. Cada uno de estos requiere una columna nueva de dimensión en la
tabla de hechos, como se muestra en la figura.

Marcelo Magaña
8. Solución Técnica
a) Construyendo Tablas de dimensiones
I. Aunque existen algunas diferencias de menor importancia en los diseños
de mesa de soluciones de negocio, la mayoría de dimensiones y
estructuras de la tabla de hechos por lo general siguen un patrón muy
similar. Algunas formas estándar de acercarse a los requisitos para un
almacén de datos que funcionan bien son comunes en la mayoría de
bases de datos modernas, como SQL Server 2005. Podemos empezar por

Marcelo Magaña
la construcción de la tabla de buques método para demostrar la dimensión

de enfoque.
II. Usando llaves sustitutas
Cada tabla de dimensiones tiene una columna sustituto clave que se
genera en el almacén de datos y la identifica de forma única el registro
dimensión. En las bases de datos SQL Server, podemos implementar
claves suplentes con un concepto llamado las columnas de identidad.
La primera columna que vamos a añadir a la tabla de dimensión se llama

ShipMethodKey (véase el recuadro "Uso de normas de denominación"),
que es la clave sustituta de la tabla. Todas las claves suplentes en
nuestras bases de datos se declaran como campos enteros con la
propiedad IDENTITY activada. Esto significa que no hay necesidad de
especificar un valor para esta columna. La base de datos se generará un
valor incremental único cada vez que se agrega una nueva fila a la tabla.
III.Agregando la llave de negocios
El fabricante tiene asignado un código para cada método de envío de
productos a sus clientes, tales como OSD para envío al extranjero de
lujo. A pesar de que son internamente con la clave sustituta como el único
identificador para métodos de envío, todavía tenemos que almacenar el
código de envío original, junto con todos los registros. Este código será
utilizado para traducir los códigos de envío de la información recibida de
los sistemas de origen y se conoce como la clave del negocio.
A diferencia de las llaves de alquiler, todas las claves de negocio en el

almacén de datos puede tener un tipo de datos diferentes, por lo que debe
tomar una decisión para cada tabla de dimensiones. Los códigos de
método de envío en la actualidad tres caracteres identificadores en los
sistemas de origen, por lo que char (3), probablemente sería un buen
candidato aquí. Algunos diseñadores de almacenes de datos como para
Marcelo Magaña
añadir algo de espacio adicional en los códigos para hacer frente a

cualquier sistema de futuro que podría ser necesario que el uso integrado
de códigos de tiempo, pero debido a que generalmente es un ejercicio
trivial cambiar este tamaño si es necesario (sobre todo en las tablas de
dimensiones , que suelen ser mucho más pequeñas que las tablas de
hechos), esto es, sin duda opcional.
claves de negocios tienden a tener una gran variedad de nombres en los

sistemas de fuente (por ejemplo, Registro del cliente,
ShippingMethodCode o ProductID), por lo que tomará la convención de
nomenclatura coherente agradable de usar ShipMethodBusinessKey y
seguir esto para todas las claves de nuestro negocio. Al crear la columna,
recuerde que las claves de negocio en general, no debe permitir que los
nulos.
También vamos a añadir una restricción de clave única para la columna

ShipMethodBusinessKey y para todas las columnas de negocios clave en
nuestras mesas de otra dimensión. Debido a que va a utilizar la clave de
negocio para buscar los registros del sistema de origen, la restricción de
clave única se asegurará de que no tenemos todos los duplicados que
haría que este proceso no.
IV. Agregando índices a las tablas de dimensiones

La restricción de clave única que hemos añadido a la clave del negocio
también ofrecerá un índice en la columna, y vamos a tomar este índice
como el índice agrupado de la tabla de dimensiones. Esto significa que los
datos de la tabla será físicamente en orden de las claves del negocio, lo
que mejorará el rendimiento cuando tenemos que buscar el registro
dimensión basada en la clave del negocio.Por ejemplo, cuando un registro
dimensión se recibe de los sistemas de origen, el proceso de ETL se
Marcelo Magaña
necesita hacer una búsqueda utilizando la clave del negocio para

determinar si el registro es nuevo o es un registro existente que se haya
cambiado.
Los almacenes de datos que se utilizan principalmente como un almacén

coherente para cargar cubos de Analysis Services en realidad necesitan
de indexación poco porque todas las consultas del usuario final tiene lugar
en el cubo, pero con un diseño cuidadoso de indexación que incluye las
claves de sustitutos utilizados en la relacional se une a mejorar el
rendimiento para las aplicaciones que se ejecutan las consultas
directamente contra el almacén de datos, tales como los informes
relacionales.
V. Agregando atributos descriptivos

Todas las demás columnas de nuestra tabla de dimensiones del buque
son los atributos método descriptivo que se puede utilizar para analizar la
información. Durante la fase de modelado de datos, siempre vamos a
tratar de incluir el mayor número de estos atributos como sea posible para
aumentar la utilidad de nuestro almacén de datos. Los atributos tienen
diferentes tipos de datos según el tipo de información (tales como el costo
de envío de divisas y las tasas sobre la dimensión del buque Método),
pero muchos de ellos contienen información textual.
Cuando usted está construyendo un nuevo almacén de datos, a menudo

encontrar patrones en los tipos de datos que está utilizando para los
atributos, tales como tener algunas columnas con una breve descripción
de hasta 50 caracteres y columnas de otros con una mayor descripción de
100 caracteres. Una técnica útil es tomar ventaja de los tipos definidos por
el usuario de SQL Server función para crear tipos de datos especiales
para las categorías comunes de las columnas, como ShortDesc y
Marcelo Magaña
longdesc. Esto estandarizará su enfoque para la creación de los atributos,

y que sea más fácil cambiar las columnas si cambia el enfoque.
b) Creando una tabla de dimensión:

I. Abrir SQL Server Management Studio
II. Si se le pide que se conecte al servidor de base de datos, seleccione el
tipo de autenticación y haga clic en Conectar. Si esta es la primera vez
que está abriendo el Management Studio, seleccione Conectar Explorador
de objetos en el menú Archivo, seleccione Motor de base como tipo de
servidor y seleccione el nombre del servidor de base de datos.
III.Para crear una nueva base de datos, haga clic en la carpeta Bases de
datos en el Explorador de objetos y seleccione Nueva base de datos, a
continuación, especificar un nombre para su base de datos, tales como
ManufacturingDW, y haga clic en Aceptar para crearla.
IV. En el panel Explorador de objetos, expanda la carpeta Bases de datos y
encontrar su nueva base de datos, a continuación, expanda la carpeta de
base de datos para ver las carpetas tipo de objeto, como la base de datos
de diagramas y tablas.
V. Para crear la tabla nueva dimensión, los cuadros botón derecho del ratón
y seleccione Nueva tabla. Una nueva ventana se abrirá en Management
Studio que le permite especificar las columnas y otros ajustes. (Se le pide
que nombre de la tabla sólo cuando lo guarda.)
VI. Para la primera columna, especifique ShipMethodKey como el nombre y la
int como el tipo de datos, y desactive la casilla Permitir valores nulos. En
las propiedades de la columna, abre la sección Especificación de
identidad y establecer la propiedad (Identidad) en Sí.
VII. Para especificar la nueva columna como clave principal, haga clic
en la columna ShipMethodKey y elija Establecer clave principal.

Marcelo Magaña
VIII. En la fila de la cuadrícula siguiente, agregar la columna

ShipMethodBusinessKey con un tipo de datos de char (3), y desactive la
casilla Permitir valores nulos.
IX. Haga clic en la tabla y elija Índices o claves. Tiene que cambiar la
propiedad Crear Como en clúster de la clave principal existente que no,
porque cada tabla sólo puede tener un índice agrupado, y vamos a añadir
una clave para el negocio en su lugar.
X. Para agregar una restricción única clave para el negocio clave, haga clic
en el botón Agregar para crear un nuevo índice. Por la propiedad
Columns, seleccione ShipMethodBusinessKey, cambie la propiedad Tipo
de clave exclusiva, y cambia la propiedad Crear Como agrupados en
Sí. Haga clic en el botón Cerrar para volver a la mesa de diseño.
XI. Agregar las columnas de otros atributos descriptivos de la dimensión del
buque Método (véase el modelo de datos), utilizando varchar (25) como el
tipo de datos para el nombre del método de los buques y dinero para las
otras columnas, como se muestra en la Figura siguiente
XII. Haga clic en el botón Guardar de la barra de herramientas y
especifique DimShipMethod como el nombre de la tabla.

Marcelo Magaña
c) Construyendo la Tabla de Dimensión tiempo

I. El Horario tiene un registro por cada período de tiempo que estamos
midiendo, que es por día para el ejemplo de fabricación. El cuadro se
compone de los atributos descriptivos para apoyar las diversas jerarquías,
como Calendario y Fiscal, así como otros atributos descriptivos, tales
como el número de días del año o si el día es un día festivo.
A pesar de que podría seguir la convención habitual de utilizar una clave

de entero sustituto genera automáticamente, a menudo es conveniente
para las tablas de dimensión de tiempo para utilizar una columna de fecha

Marcelo Magaña
y hora actuales como la clave principal. Debido a que la fecha real es el

valor que se sabe que los sistemas de origen, esto es básicamente el
equivalente de la utilización de la clave de negocios en lugar de un
sustituto generado. Esto viola las directrices de diseño de utilizar siempre
una clave sustituta, pero hace algunos procesos como la carga de la tabla
de hechos más fácil, evitando la necesidad de buscar la clave suplente
para cada fecha en la que se encuentra.
Para apoyar la dimensión de Analysis Services que en última instancia, se

construyen a partir de la tabla de tiempo, también tenemos que añadir una
columna adicional única para cada nivel en las jerarquías. Por ejemplo, el
atributo Nombre Barrio contiene valores como el Barrio 1 y 2 º trimestre,
que no son únicos, ya que cada año tiene los mismos cuatro nombres
trimestre. Vamos a añadir un barrio columna de clave utilizando la fecha
del primer día en el barrio de proporcionar un valor único para cada
trimestre, como por ejemplo 01/01/2006, y tener el mismo enfoque para
los otros niveles como el Año y Mes.
Después de haber terminado el diseño de todas las tablas de dimensiones

del almacén de datos, podemos pasar a las tablas de hechos. .
d) Construyendo Tablas de Hechos

I. La tabla de hechos consiste en una columna que contiene la clave
suplente para cada dimensión relacionada con la tabla de hechos, así
como las columnas de las medidas que vamos a realizar el
seguimiento. Para la tabla de hechos envíos, tenemos que añadir la
ProductKey, SalesTerritoryKey, PlantKey y columnas ShipMethodKey. La
tabla de hechos tiene dos relaciones con la dimensión del cliente, por lo
que tenemos que añadir por separado ShippingCustomerKey y columnas
BillingCustomerKey para representar esto. También tenemos tres llaves
Marcelo Magaña
fecha (OrderDateKey, DueDateKey y ShipDateKey) para representar las

diferentes fechas para cada hecho de envío.
La mayoría de las tablas de hechos contienen un registro único para cada

combinación distinta de los valores fundamentales, por lo que la clave
principal lógica de la tabla de hechos es por lo general todas las claves de
dimensión. Sin embargo, la mayoría de la información se analiza con
cierto nivel de resumen (sobre todo utilizando soluciones de BI Analysis
Services), por lo que muchas veces no importa si usted tiene varios
registros de la misma combinación de claves, ya que se sumarán, salvo
en algunos casos los informes relacionales. Por este motivo, una
restricción de clave principal es por lo general no se agregan a las tablas
de hechos, así como cualquier posible requisito para evitar registros
múltiples hecho se maneja en la carga de datos (ETL).
Como se ha descrito para las tablas de dimensiones, soluciones de BI que

utilizan cubos de Analysis Services para consultar la información que
requieren la indexación poco en el almacén de datos. Vale la pena, sin
embargo, para agregar un índice agrupado a la tabla de hechos, por lo
general en una de las claves de la fecha. Debido a que los datos a
menudo se preguntó por un intervalo de fechas, será útil disponer de los
datos de hechos físicos dispuestos en orden de fecha. Para la tabla de
hechos envíos, vamos a utilizar la fecha más temprana, que es el
OrderDateKey, como se muestra en la figura siguiente. Si usted también
está haciendo los informes relacionales de las tablas de almacenamiento
de datos, es probable que demostrar ser beneficiosos para agregar los
índices para las claves de dimensión en la tabla de hechos, ya que esto
acelerará se une a las tablas de dimensiones.

Marcelo Magaña
Después de las llaves, podemos agregar las columnas restantes medida

con el menor tipo de datos que puede contener la medida en el nivel de
detalle. Vale la pena tener cuidado con este proceso, porque las tablas de
hechos son las tablas más grandes en el almacén de datos, y bien
seleccionados los tipos de datos puede ahorrar mucho espacio y dar lugar
a un mejor rendimiento. La desventaja de elegir un tipo de datos que es
demasiado pequeño, es que en algún momento, el proceso de carga de
datos, probablemente se producirá un error y necesitan ser renovadas
después de aumentar el tamaño de la columna.
e) Usando vistas u objetos encapsulados

I. Si permitimos que las aplicaciones cliente, tales como herramientas de
informes o cubos de Analysis Services para acceder directamente a las
tablas en nuestro almacén de datos, se corre el riesgo de que cualquier
Marcelo Magaña
cambio futuro que hacemos puede romper estas aplicaciones. En su lugar,

puede crear una vista para cada tabla de dimensiones y el hecho en el
almacén de datos, lo que hace que sea más fácil cambiar u optimizar la
estructura de base de datos subyacente sin que necesariamente afectan a
las aplicaciones cliente que utilizan la base de datos.
Puede diseñar puntos de vistas con SQL Server Management Studio,

haciendo clic derecho en la carpeta Vistas en la base de datos y la
selección de Nueva vista. El diseñador de consultas le permite agregar las
tablas de origen a la vista y seleccione las columnas que se incluyen, y
especificar un nombre al guardar la nueva vista.
f) Tratando con Integridad de referencias
La integridad referencial (RI) es una técnica para preservar las relaciones
entre las tablas y se utiliza a veces en las soluciones de almacenamiento de
datos para asegurarse de que todas las claves en las filas de la tabla de
hechos tiene una fila de dimensión correspondiente. Si el proceso de carga
de datos intenta agregar una fila de datos con una clave de dimensión que
todavía no existe, el proceso fracasará debido a la restricción de RI y
asegurarse de que no terminen con los hechos no coinciden.
Buenos argumentos a favor y en contra del uso de restricciones de integridad

referencial en el almacén de datos existen (y los autores han utilizado o
escuchado la mayoría de ellos), pero vamos a salir a un miembro aquí y decir
que en una base de datos correctamente diseñada y gestionada almacén, las
limitaciones de RI no son necesarios. La razón principal de esto es que
siempre usamos claves suplentes para las dimensiones. Debido a que estas
claves sólo son conocidas en el almacén de datos, una "búsqueda" paso
siempre debe tener lugar durante la carga de traducir los hechos claves de
negocio en claves suplentes. Si este paso búsqueda falla, el nuevo disco no
sea que añadir a la tabla de hechos o se agregó con una clave sustituta
Marcelo Magaña
especial que se refiere a una "falta" o "Desconocido" registro dimensión.
Así, a diferencia de los sistemas OLTP en RI es una necesidad absoluta, una

característica importante de los almacenes de datos que utilicen
exclusivamente claves suplentes es que de RI se cumple a través del proceso
de carga de datos. Por esta razón, no es necesario declarar las restricciones
de clave en el data warehouse. Las ventajas son que se mejora el
rendimiento de carga, y la carga de datos de secuencia a veces puede ser
más flexible. La única desventaja potencial es que los errores en su proceso
de carga de datos son más difíciles de atrapar hasta que se intenta validar los
números de su almacén de datos, por lo que a veces resulta útil para
encender las restricciones de clave durante el proceso de desarrollo.
Es sólo cuando haya excepciones a la regla de utilizar siempre una clave

sustituta que se meten en problemas, y un lector especial de alerta se habrán
dado cuenta que ya hemos roto esta regla para uno de nuestras tablas La
dimensión de tiempo. Las claves de la fecha en nuestra tabla de hechos son
las columnas de fecha y hora y no necesita ser consultado en la tabla de
dimensiones durante la carga. Esto significa que tendremos que añadir un
poco de procesamiento en el proceso de carga de datos para comprobar que
todos los datos en los registros de hecho nuevo cae en el intervalo de fechas
que figuran en la tabla de dimensiones de tiempo, y para iniciar un proceso
para tener más fechas añadidas si no.

Marcelo Magaña

Trabajo GBI6501

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Trabajo GBI6501

Cargado por

Copyright:

Formatos disponibles

Instituto Profesional

DuocUC – Sede Puente Alto.

Guía de Trabajo GBI

I) Desarrolle los siguientes pasos, según se indica en el documento

1. Nuestro cliente es una empresa de tamaño medio, que produce bienes

2. La información disponible está restringida por la funcionalidad del actual ERP

3. Se tienen los siguientes problemas:

c) El uso de los sistemas ERP para retornar la información está afectando

4. Usted construirá un DataWarehouse que consolide la información de los

5. Requerimientos del Negocio:

6. Arquitectura de Alto Nivel

Página 2 de 28 GESTION DE NEGOCIOS CON BUSINESS INTELLIGENCE

Como resultado, la definición de los procesos de negocio exacta que tenemos

Página 3 de 28 GESTION DE NEGOCIOS CON BUSINESS INTELLIGENCE

la información de la fabricación (lo que es el costo real de los productos

En cierto modo, esta cuestión de modelado de datos de granularidad es el

En los malos viejos tiempos antes de la tecnología se encontró con nuestras

fácilmente apoyo a la información detallada a nivel sin un tratamiento especial

Página 5 de 28 GESTION DE NEGOCIOS CON BUSINESS INTELLIGENCE

enviado, y método de envío, que indica el método utilizado para enviar el

Página 6 de 28 GESTION DE NEGOCIOS CON BUSINESS INTELLIGENCE

Tenga en cuenta que cada tabla de dimensiones de copo de nieve todavía

El fabricante de nuestro ejemplo tiene un tema interesante con

Página 7 de 28 GESTION DE NEGOCIOS CON BUSINESS INTELLIGENCE

II. Información de Clientes

Cada cliente se encuentra físicamente en una dirección, y se puede ver

por zonas de venta.

En nuestro modelo de datos, vamos a extraer la información física

Página 9 de 28 GESTION DE NEGOCIOS CON BUSINESS INTELLIGENCE

Lo primero que tenemos que determinar es el nivel de detalle necesario

Porque la mayoría de las aplicaciones modernas incluyen extensas

Página 10 de 28 GESTION DE NEGOCIOS CON BUSINESS INTELLIGENCE

Analysis Services para proporcionar la capacidad de seleccionar los

Sugerencia: No incluya registros por hora o minuto

Usuarios más probable es que desea seleccionar un rango de fechas y

Página 11 de 28 GESTION DE NEGOCIOS CON BUSINESS INTELLIGENCE

registro por cada período de tiempo, como un total de 1.440 registros de

La otra característica útil que le puede proporcionar en una dimensión de

IV. Qué estamos midiendo?

Página 12 de 28 GESTION DE NEGOCIOS CON BUSINESS INTELLIGENCE

Sugerencia: la importancia de aclarar los términos.

En última instancia, la fuente de todas las medidas en una tabla de hechos

diseños, mientras que mucha de la información en los almacenes de datos

Por ejemplo, una medida candidato obvio es la cantidad del elemento

V. Unidades de medida numéricas que no se pueden sumar.

promedio durante el período de tiempo que está consultando.

La misma lógica se aplica generalmente para "equilibrar" los tipos de

A menudo es posible transformar la "tasa" medidas en medidas totalmente

VI. Manejo de relaciones complejas con Dimensiones

Cada envío que hacemos es enviado a un cliente específico, por lo que

La dimensión de tiempo tiene un requisito similar. Dependiendo del

Página 16 de 28 GESTION DE NEGOCIOS CON BUSINESS INTELLIGENCE

Página 17 de 28 GESTION DE NEGOCIOS CON BUSINESS INTELLIGENCE

la construcción de la tabla de buques método para demostrar la dimensión

La primera columna que vamos a añadir a la tabla de dimensión se llama

A diferencia de las llaves de alquiler, todas las claves de negocio en el

añadir algo de espacio adicional en los códigos para hacer frente a

claves de negocios tienden a tener una gran variedad de nombres en los

También vamos a añadir una restricción de clave única para la columna

IV. Agregando índices a las tablas de dimensiones

necesita hacer una búsqueda utilizando la clave del negocio para

Los almacenes de datos que se utilizan principalmente como un almacén

V. Agregando atributos descriptivos