1. THE DATA
WEBHOUSE
1.0 Introducción
Usuarios finales están cada vez más los desarrolladores de aplicaciones crear aplicaciones en torno a
las páginas Web. La interfaz de usuario entorno de desarrollo de la elección es ahora una página web
entorno de desarrollo. El almacenamiento de datos es una de las principales responsabilidades de la
tecnología de la información. En muchas formas de almacenamiento de los datos cumple con la
promesa de "obtener los datos a cabo" después de que el sistema OLTP basado en "recibe los datos
en formato". La revolución de la web ha ciertamente no sustituye la necesidad de que el almacén de
datos. De hecho, la revolución de Internet ha aumentado las expectativas de todo el mundo mucho
más alto que todo tipo de información será publicada a la perfección a través de la interfaz del
navegador web. La audiencia de los datos de almacenamiento de datos ha pasado de la gestión
interna para abarcar a los clientes, socios y la piscina más grande de los empleados internos. El
enfoque de la web sobre la experiencia de los clientes ha hecho que muchas organizaciones tanto de
conocer al cliente y dar al cliente información útil.
La revolución de Internet ha impulsado el almacén de datos a cabo en el escenario principal, ya que
en muchas situaciones, el almacén de datos debe ser el motor que los controles o análisis de la
experiencia web. Con el fin de acelerar esta nueva responsabilidad, el almacén de datos debe
ajustar. La naturaleza del almacén de datos tiene que ser algo diferente. (Kimball, pág 4) Como
resultado, nuestros almacenes de datos se están convirtiendo en webhouses de datos. El almacén de
datos se está convirtiendo en la infraestructura que soporta la gestión de relaciones con clientes
(CRM). Y el almacén de datos que se pide para hacer el seguimiento de clic al cliente disponible para
el análisis. Este renacimiento de la arquitectura de almacenamiento de datos se llama el WEBHOUSE
de datos. (Kimball, 1999 (julio))

2. 2,0 La necesidad de Webhouses datos
Considere la posibilidad de que los analistas de marketing. Hace cinco años que estaban diciendo,
" Muypronto vamos a tener bases de datos el registro de cada interacción con el cliente, no
importa lo aparentemente insignificante .... "Entonces, que pasaría a predecir la forma en que el
santo grial, el expediente completo al cliente, que nos permiten entender comportamiento de los
clientes, los intereses y necesidades con más profundidad que nunca antes. A partir de ese
entendimiento vendría el crecimiento, el beneficio, la satisfacción del cliente - todo lo que un ejecutivo
de negocios que pueda desear.
Pues bien, cuando se trata del registro de cliente completo, la Internet ha permitido que el genio de la
botella. El " clics ", que el registro de cada clic del ratón o pulsaciones de todos los visitantes a un sitio
Web, ha generado un registro de clientes más completo que jamás haya existido en cualquier forma
de comercio. (Kimball, 2000 (abril))
El WEBHOUSE de datos es una instancia web del almacén de datos. El WEBHOUSE juega un papel
central y un papel crucial en las operaciones del negocio en la Web habilitada. El WebHouse datos
voluntad,
 Casas y publica los datos haga clic en los ríos y otros datos sobre el comportamiento de
la web que impulsan la comprensión del comportamiento del cliente.
 Servir de base para la toma web habilitada para hacer. El WEBHOUSE de datos debe permitir
a sus usuarios a tomar decisiones sobre la web, así como tomar decisiones utilizando la web.
 Actuar como un medio que publica los datos a los clientes, socios comerciales y empleados
de manera apropiada, pero al mismo tiempo que protege los datos de la empresa contra el
uso sin supervisión.
3.0 Los datos WebHouse Arquitectura
Exigencias creadas en la Web está dibujando el almacén de datos cada vez más cerca de la línea
de información operativa y la generación de la respuesta operativa, lo que obliga a repensar la
arquitectura de almacenamiento de datos. Hoy en día está aumentado drásticamente el ritmo de
toma de decisiones empresariales no sólo requiere una visión completa del negocio en tiempo
real, pero a la vez, las respuestas a preguntas generales sobre el comportamiento del cliente. El
almacén de datos se está llevando a la etapa central en la revolución de Internet, y se requiere
replantear y ajustar nuestro modo de pensar de almacenamiento de datos.
Creemos que los datos WebHouse es una variación de un almacén de datos tradicional. Sin
embargo, la arquitectura de un WebHouse de datos es diferente de un almacén de datos.
3.1 Características de la WebHouse de datos

3. Este "WebHouse de datos" debe:
 Estar diseñado desde el principio como un sistema totalmente distribuido, con
muchos nodos desarrollados independientemente que contribuyen a la totalidad en
general. En otras palabras, no hay un centro a la WebHouse datos.
 No ser un sistema cliente / servidor, pero un sistema habilitado para la Web. Esto
significa un rediseño de arriba a abajo. Un sistema habilitado para la Web ofrece los
resultados y expone sus interfaces remotos a través de navegadores en la Web.
 Tratar igual de bien con texto, secuencias de datos numéricos, gráficos,
fotográficos, de audio y video, porque la web ya es compatible con esta mezcla de
medios de comunicación.
 Soporte a nivel atómico datos de comportamiento por lo menos en el nivel de
terabyte de data marts muchos, especialmente aquellos que contienen datos de
seguimiento de clics.Muchos análisis de comportamiento debe, por definición, se
arrastran por el nivel más bajo de los datos debido a las limitaciones de análisis
opone a que los resume con anticipación.
 responder a una petición del usuario final en aproximadamente 10 segundos,
independientemente de la complejidad de la solicitud
 Incluir la eficacia de la interfaz de usuario como criterio principal de diseño. La
única cosa que importa en el WebHouse de datos es la publicación efectiva de la
información en la Web.Los retrasos, diálogos confusos, y la falta de las opciones
deseadas son todas las fallas directas. (Kimball, 1999, junio)
Con esta evolución de almacenamiento de datos, hemos conseguido hacer tres grandes
factores de diseño técnico más difícil.
o Desafíos en datos de diseño WebHouse
 puntualidad. resultados de negocio ya debe estar disponible en tiempo
real. "A partir de el día anterior" se informa, en la lista de deseos hace dos años,
ya no es un ritmo suficiente. Tuberías de suministro cada vez más eficientes con
menores, justo a tiempo los inventarios, junto con la personalización en masa, nos
obligan a entender y responder rápidamente a la demanda.
 volúmenes de datos. El gran movimiento de la personalización en masa
significa que ahora capturar, analizar y responder a todas las transacciones en el
negocio, incluyendo todos los gestos que un cliente realiza, antes y después de
operaciones o transacciones de venta y no parece que no hay límite de
volumen. Por ejemplo, la combinación de Microsoft relacionados con sitios web,
analizar diariamente como una sola entidad, en algunos días de gran afluencia
han capturado a más de mil millones de eventos de página!
 tiempos de respuesta. La web hace tiempos rápidos de respuesta crítica. Si
algo útil no ocurre dentro de los 10 segundos, el usuario puede navegar a otra

4. página. Aquellos de nosotros que corren grandes almacenes de datos sabemos
que muchas consultas se llevará a más de 10 segundos. (Kimball, 2000, p31)
o de muestras de datos WebHouse Arquitectura
A medida que estos factores de diseño se han convertido en más difícil, nos
encontramos un continuo apoyo más amplio de usuarios y solicitudes. Para abordar
estas cuestiones, tenemos que ajustar nuestra arquitectura de almacenamiento de
datos. No podemos hacer que nuestro servidor de base de datos única cada vez
más poderosa. No podemos hacer realidad todos estos objetos complicados y la
esperanza de mantenerse al día con estos requisitos cada vez mayores.
El siguiente diagrama explica claramente la una muestra de datos software
arquitectura de la casa.
Nota: -
(Debido a las limitaciones de palabras que tengo se abstengan de explicar
lo obvio y se concentra en las distintas desviaciones y las similitudes de
la arquitectura de diseño tradicional de los datos del almacén.)

5. (Fuente: - Kimball, 2000, p 32)
3.4 Las desviaciones de la arquitectura tradicional de almacenamiento de datos.
Una forma de aliviar la presión sobre los motores de base de datos principal es construir una
potente memoria caché de respuesta en caliente (ver figura anterior) que se anticipa que
muchas de las solicitudes de información previsibles y repetidas como sea posible. El caché
de respuesta en caliente linda con los servidores de aplicaciones que alimentan el servidor
web público y el punto de entrada de servidor de seguridad privada para los
empleados. Una serie de trabajos por lotes que se ejecutan en el servidor principal de la
aplicación WEBHOUSE crea los datos de la caché.Una vez almacenados en la caché de
respuesta en caliente, los objetos de datos se pueden recuperar en la demanda ya sea a
través de una aplicación pública del servidor Web o una aplicación de servidor de
seguridad privada.

6. Los elementos son objetos complejos descabellada archivo, no de bajo nivel los elementos
de datos. El caché de respuesta en caliente es por lo tanto, un servidor de archivos, no una
base de datos. Su jerarquía de almacenamiento de archivos, inevitablemente, será un tipo
simple de la estructura de búsqueda, pero no es necesario para apoyar un método de
consulta de acceso complejo.
3.4.1 Las características de la "caché de respuesta en caliente".
 saludos personalizados a los visitantes de la web, que consta de texto y
gráficos
 dinámicamente el contenido elegido el ascenso a visitantes de la web
 basado en XML (Extended Markup Language), estructurado de forma de
contenido a los socios comerciales (lo que solemos llamar EDI) que solicitan el
estado de entrega, el estado de orden, de abastecimiento en el inventario (que
utiliza para medir días de horas de suministro, que se está volviendo obsoleto ), y los
críticos de ruta advertencias en la tubería de transporte
 preguntas frecuentes de bajo nivel-como respuestas a los problemas y
solicitudes de apoyo
 de primera línea a los informes de gestión, que requieren una integración
significativa en el tiempo (varios años las tendencias), clientes, líneas de productos o
geografías todo ello en tres formatos intercambiables que incluyen la página
orientada informe de tabla dinámica y gráfico, y con frecuencia acompañadas de
imágenes
 Juegos descargables precalculadas cubos OLAP para el análisis exploratorio
de
 estudios de minería de datos, tanto a corto plazo y largo plazo, mostrando la
evolución demográfica de los clientes y grupos de comportamiento, y los efectos
de las decisiones sobre el contenido de la promoción y el contenido del sitio Web
de negocios realizados a través de la web
 agrupaciones convencionales que mejoran el rendimiento de consulta cuando se
perfora a través de jerarquías estándar en las dimensiones más importantes, como
cliente, producto, y el tiempo. (Kimball, 2000, p34)
La administración de la caché de respuesta en caliente debe ayudarle a apoyar las
necesidades de los servidores de aplicaciones ". Idealmente, un trabajo por lotes se han
calculado y se almacena en el avance del objeto de información que necesita el servidor
de aplicaciones. Todas las aplicaciones tienen que ser conscientes de que la caché de
respuesta en caliente existe y debe ser capaz de investigar para ver si la respuesta que ellos
quieren es que ya existe. El caché de respuesta caliente tiene dos modos distintos de uso, la
naturaleza de la sesión de visitante solicitando los datos determina cuál usar.
La solicitud de tiempo de respuesta garantizado debe producir algún tipo de respuesta en
respuesta a una solicitud de página que el servidor Web está manejando, por lo general en
menos de un segundo. Si el objeto solicitado (por ejemplo, un saludo personalizado, una
propuesta personalizada de cross-selling, un informe de inmediato, o una respuesta a una
pregunta) no ha sido previamente y por lo tanto, no se almacena, un objeto de respuesta

7. por defecto debe ser entregado en su lugar, todo ello en el tiempo de respuesta
garantizado.
La solicitud de tiempo de respuesta acelerado de espera para producir una respuesta a la
petición del visitante web, sino que pondrá por defecto en el cálculo de la respuesta
directamente desde el almacén de datos subyacente si el objeto calculado previamente
no se encuentra inmediatamente.
El servidor de aplicaciones opcionalmente debe ser capaz de avisar al usuario de que
puede haber un retraso en el suministro de la respuesta en este caso. El servidor Web tiene
que ser capaz de alertar al servidor de aplicaciones si se detecta que el usuario ha pasado
a otra página, por lo que el servidor de aplicaciones puede detener el proceso de
almacenamiento de datos.

8. 3.5 Similitudes con almacenes de datos tradicionales
Tenga en cuenta que esta estrategia de buscar una respuesta previamente y moroso si es
necesario para los datos de base es exactamente la manera que los agregados
convencionales siempre han trabajado en el almacén de datos. El navegador de
almacenamiento de datos global siempre ha buscado para los agregados para responder
a las partes de un informe de consultas en general. Si el navegador encuentra el agregado,
que lo utiliza. Pero si no encuentra el agregado, con gracia por defecto es el cálculo de la
respuesta lenta de los datos de base.Visto de esta manera, la caché de respuesta en
caliente es una especie de navegador sobrealimentado agregado. (Kimball, 2000, p35)
Como podemos ver datos WebHosue es un refinamiento, no una desviación distinta de la de
almacenamiento de datos tradicional.
4.0 La construcción del almacén de datos
Una parte interesante de la WEBHOUSE emergente de datos es el mercado de datos que almacena y
presenta la actividad en la Web para su posterior análisis. Fundamentalmente, queremos analizar
todos los accesos a nuestro sitio web. Queremos construir una visión comprensible de la corriente
inmensa de clics que llegan a nuestros sitios, ya sea que estemos tratando con nuestros usuarios de la
intranet o con los clientes en nuestro público el sitio web. Llamamos a este aspecto de nuestros datos
WebHouse la "secuencia de clics los datos de mercado. "
4.1 Los objetivos de la Mart clics de datos
El mercado de datos de clics puede decirnos mucho sobre el comportamiento del cliente
detallada. Si tenemos información sobre nuestros clientes, cada clic y el gesto a través de
nuestro sitio web, debemos ser capaces de responder a preguntas tales como:
 ¿Qué partes de nuestro sitio web obtener la mayoría de los visitantes?
 ¿Qué partes del sitio web no se asocian más frecuentemente con las ventas reales?
 ¿Qué partes del sitio Web son superfluos o visitado con poca frecuencia?
 Cuáles son las páginas de nuestro sitio Web parece ser "asesinos de sesión", donde el
usuario remoto se detiene la sesión y se va?
 ¿Cuál es el perfil de los visitantes de nueva clic en nuestro sitio?
 ¿Cuál es el perfil de clic de un cliente existente? Un cliente rentable? Un cliente que se
queja de que con demasiada frecuencia, devuelve nuestro producto?
 ¿Cuál es el perfil de un cliente haga clic en a punto de cancelar su servicio, se quejan, o
presentar una demanda?
 ¿Cómo se puede inducir al cliente a inscribirse en nuestro sitio por lo que aprender un
poco de información útil acerca de ese cliente?
 ¿Cuántas visitas se suelen hacer los clientes no registrados con nosotros antes de que
estén dispuestos a registrarse? Antes de comprar un producto o servicio?

9. Dada esta información, ¿podemos imaginar la construcción de la clickstream data mart con corte
convencional y dados los modelos dimensionales? Y si logramos construir, ¿cómo podemos esperar
para analizar el mercado de datos de clics para responder a todas estas preguntas?
4.2 Edificio de clics Data Mart
Para construir el mercado de datos de clics, vamos a usar un simple, la metodología de
cuatro pasos para construir el modelo tridimensional.
 Definir el origen de nuestros datos,
 Elegir el grano de nuestra tabla de hechos,
 Elija las dimensiones apropiadas para que el grano
 Elegir los hechos apropiados para ese grano.
4.2.1 El origen de datos para el Mart clics de datos
Tenemos que ir después de los datos lo más afinada posible y detallada descripción
de los clics en nuestro servidor web. Cada servidor Web potencialmente informar de
los detalles diferentes, pero en el nivel más bajo que debe ser capaz de obtener un
registro por cada página de golpear con la siguiente información: fecha exacta y la
hora de página, haga clic, el cliente remoto (que solicita del usuario) la dirección IP,
solicitó la página (con la ruta a la página a partir de la máquina del servidor), el
control específico de descarga, y información de la cookie, si está disponible.
El problema más grave, que impregna todos los análisis de comportamiento en la
Web haciendo clic, es que las visitas a la página a menudo son apátridas (no
recuerda lo que el usuario hizo en la última página). Sin rodea contexto, una visita a
la página sólo puede ser un evento al azar aislado que es difícil de interpretar, como
parte de una sesión de usuario. Tal vez el usuario accedió a esta página desde
algún sitio Web remoto, y luego a la izquierda de la página cinco segundos más
tarde sin tener que regresar. Es difícil tener mucho sentido a cabo de tal evento, así
que nuestro primer objetivo es identificar y etiquetar las sesiones completas.
El segundo problema grave es si podemos hacer ningún sentido fuera de la
dirección IP del cliente remoto. Si la identificación del cliente sólo es la dirección IP,
no podemos aprender mucho. La mayoría de los usuarios de Internet vienen a través
de un proveedor de servicios Internet (ISP) que asigna direcciones IP
dinámicamente. De este modo, los usuarios remotos tener una dirección diferente
en una sesión posterior de lo que tenemos en este momento. Probablemente
podamos realizar un seguimiento de la sesión individual de forma fiable, pero no
podemos estar seguros de cuando el usuario vuelve al sitio en una sesión diferente.
Nos puede reducir significativamente estos problemas si nuestro servidor web crea
cookies en la máquina del usuario solicitante. Una cookie es un fragmento de
información que el usuario que solicita "de acuerdo" para almacenar y estar de
acuerdo para enviar a su servidor web cada vez que su navegador se abre una de

10. sus páginas. Una cookie normalmente no contiene mucha información, pero se
puede identificar el ordenador del usuario que solicita de forma
inequívoca. Además, proporciona una forma de vincular visitas a la página a través
de una sesión de usuario completa. Una cookie puede contener información
importante si el usuario ha registrado de forma voluntaria con su servidor web y
proporcionar otra información, como el nombre verdadero bien humano y una
afiliación de la compañía. En tal caso, la cookie permite una identificación a los
datos que ha almacenado en una de sus propias bases de datos.
A fin de que los datos de navegación primas utilizables en nuestro WEBHOUSE de
datos, que necesitamos para recoger y transformar los datos por lo que tiene una
perspectiva de la sesión. Este proceso será un paso significativo en la trastienda. Se
supone que tenemos algún tipo de mecanismo de la cookie que nos permite
transformar nuestro origen de datos en el siguiente formato:
• La fecha exacta y hora de visita a la página
• Identidad del usuario que solicita (consistente de una sesión a otra)
• ID de la sesión
• Página de eventos y solicitado.
4.2.2 El grano fundamental de la Mart clics de datos
Ahora vemos que cada evento de un usuario individual invoca en una sesión
especial es el grano de nuestra tabla de hechos clickstream data mart. Cada
evento es un registro individual, y cada registro es un evento en una página
Web. Tenga en cuenta que el servidor Web no puede observar los acontecimientos
dentro de la interfaz de usuario de una página Web descargada a menos que haya
programado la página Web específica para alertar al servidor cuando se produce
el evento. En extracto de la trastienda y el proceso de transformación, vamos a
filtrar eventos automáticos y se centran en los más relacionados con el formato de
la página que a las acciones del usuario. Este tipo de eventos filtrados incluyen la
descarga de imágenes gráficas, tales como archivos GIF que adornan la página
solicitada. Así que si tenemos 100.000 sesiones de usuarios por día en nuestro sitio
web, y si cada sesión implica un promedio de ocho eventos significativos, entonces
vamos a recoger 800.000 registros por día. (Kimball, 2000, p158)
4.2.3 Las dimensiones (paso 3) y los hechos (paso 4)
Vea el diagrama a continuación para el modelo tridimensional del flujo de clics los
datos Mart. Las dimensiones son de fecha universal, hora universal, fecha local, hora
local, el usuario de la página, el evento, y la sesión. Nos separamos de la fecha a partir
del momento del día debido a que estos dos componentes de tiempo tienen
descriptores muy diferentes. Fecha refiere a calendario, los días laborables, y las
estaciones, y la hora del día se refiere al punto específico estamos en dentro de un
día. La mayoría de los datos de las tablas de hechos que hacen un seguimiento de
almacén momentos específicos dividir la fecha a partir de la hora del día de esta
manera. La dimensión de la fecha tiene claramente una unión real a una tabla de

11. dimensión real, con muchos atributos textuales. La dimensión temporal de la jornada
puede ser bastante aburrido como una dimensión a menos que tengamos algunos
intervalos específicos durante el día en que estamos dispuestos a asignar nombres.
(Fuente: - Kimball, 2000, p 160)
Ofrecemos dos versiones de la fecha y hora - universal y local - que nos permiten alinear los
eventos de clics en el tiempo absoluto, así como en relación con reloj de pared del
usuario.Herramienta de consulta del analista puede realizar esta alineación, pero esta
lógica adicional impone una carga excesiva para la aplicación. Por lo tanto, preferimos
ofrecer dos cableados puntos de entrada en la fecha de cada evento / marca de tiempo.
La dimensión de usuario debe contener información útil acerca de quién es el usuario, que
no sea sólo una máquina de identificación consistente. Sin embargo, esto dependerá de si
nos han inducido al usuario para que hechos reveladores acerca de su
identidad. (Kimball, 2000 (enero))
La dimensión de la página es importante porque contiene el contexto significativo que le
dice al analista de la ubicación del usuario del sitio Web. Cada página web debe contener
algunos descriptores simples que identifican el lugar y el tipo de página. Un nombre de ruta
completo no es tan interesante como estos atributos básicos como la "Información",
"Quiénes Somos", "Preguntas Frecuentes" y "Formulario de Pedido". Un sitio web de gran
tamaño debe tener una descripción jerárquica asociada a cada página que le da cada
vez más detalles acerca de lo que la página es. Esta información debe ser almacenada en
la dimensión de la página y se mantiene constante a medida que actualizar y modificar el
sitio Web. En otras palabras, tenemos que actualizar el sistema de transacciones de
producción (el servidor Web) responsablemente para satisfacer las necesidades de los
analistas WebHouse de datos.
Por último, la dimensión de la sesión es algo más que una etiqueta que agrupa a todos los
eventos de página que constituyen la sesión de un solo usuario. Esta dimensión es también
el lugar donde hemos denominado el período de sesiones y rastrear su
actividad. Podríamos caracterizar a las sesiones de "Búsqueda de información",

12. "navegación al azar", "Precio y Compras de funciones" o "hacer un pedido." Podemos ser
capaces de crear estas etiquetas con criterios simples con respecto a lo que el usuario
hace durante la sesión, o podemos entregar el registro de la sesión a un paquete de enlace
en toda regla de análisis de minería de datos. En cualquier caso, el resultado es un conjunto
de etiquetas descriptivas que pueden poner en la dimensión sesión.En la sesión también se
caracteriza por lo que sabemos actualmente sobre el cliente, tales como "gran comprador
recientes", "Todavía no es cliente," o "Returner producto crónica." (Kimball, 2000 (enero))
Nuestra tabla de hechos de clics sólo contiene un hecho, y ese hecho ("tiempo") es una
estimación. Tratamos de registrar con precisión la longitud de tiempo que el usuario emplea
en la página después de que el último clic y antes de pasar. Porque leyendo la página es,
básicamente, los apátridas, que nunca puede estar completamente seguro de si el usuario
tal vez haya minimizado la ventana o hacer clic en un sitio no relacionado. Sólo podemos
hacer una estimación precisa del tiempo dedicado a la página si tenemos un siguiente
evento que forma parte de la sesión, pero tenemos que tener cuidado de no interpretar los
largos tiempos de "gastado" demasiado en serio.

13. 4.3 Análisis de la Clickstream Data Mart
Este diseño tridimensional nos permite realizar muchas consultas de gran alcance. Es
bastante fácil de encontrar las partes más visitadas del sitio web e identificar a los usuarios
más frecuentes.También se puede correlacionar las páginas y los usuarios a nuestros clientes
más valiosos, porque sabemos que se hace el pedido en el sitio Web.
La buena noticia acerca de este diseño es que hemos establecido con éxito un marco
para la recopilación y análisis de todos los clics en nuestro sitio Web. La mala noticia es que
realmente no han arrojado mucha luz sobre si estamos vendiendo productos o servicios
Web. Esa confusión es bastante arraigada y es una de las razones por las que la revolución
de Internet es tan interesante e importante. (Kimball, 2000, p 162)

14. 5.0 Conclusión
La prisa tremenda hacia la gestión de relaciones con clientes (CRM), e-business, e inteligencia de
negocios ha llevado a muchos de los usuarios finales servicios en el mercado informático como
nuevos clientes. Esta demanda es una noticia casi en su totalidad para nosotros de
almacenamiento de datos y los implementadores de datos WebHouse. (Kimball, 2000, junio)
La web y el almacenamiento de datos se dibujan como dos potentes imanes. La web necesita el
almacén de muchas de sus clientes centrados en las funciones y el almacén se han
transformado por las demandas de la web a Webhouses de datos. Webhouses de datos tendrá un
papel importante en la cooperación mundial en un futuro muy cercano.

15. 6.0 Referencia
 Kimball. R "de datos WebHouse caja de herramientas", 2000, John Wiley & Sons
R. Kimball, "más de lo que esperaba", 2000 (abril), Intelligent
Enterprise, http://www.intelligententerprise.com/000410/scalable.shtml
Kimball R., "remover las cosas para arriba ", de 1999, (junio), Intelligent
Enterprise, http://www.intelligententerprise.com/992206/warehouse.shtml
Kimball R. "El WebHouse no tiene un centro de datos", de 1998 (julio), Intelligent
Enterprise, http://www.intelligententerprise.com/991307/warehouse.shtml
Kimball R., "Las Dimensiones Especiales de la secuencia de clics", 2000 (enero),
Intelligent Enterprise, http://www.intelligententerprise.com/000120/webhouse.shtml
R. Kimball, "Acogiendo con beneplácito la aplicación empaquetada", de 1998 (junio),
Intelligent Enterprise,