Visin de conjunto

Todos los autores de este libro trabajaron juntos en Informtica de Sistemas Metfora durante un perodo que se extendi por ms de diez aos, de 1982 a 1994. Aunque el valor real de la experiencia Metfora fue la construccin de cientos de almacenes de datos, hubo un beneficio adicional que a veces resultar til. Estamos muy conscientes de las metforas. Cmo podramos evitar las metforas, con un nombre as? Una metfora til para conseguir este libro comenz es pensar en el estudio de las piezas de ajedrez con mucho cuidado antes de tratar de jugar el juego de ajedrez. Usted realmente necesita para aprender las formas de las piezas y lo que pueden hacer en el tablero. Ms sutilmente, usted necesita aprender la importancia estratgica de las piezas y cmo utilizarlas para ganar el juego. Ciertamente, con un almacn de datos, as como con el ajedrez, hay que pensar muy por delante. Su oponente es la naturaleza siempre cambiante del entorno en el que se ven obligados a trabajar pulg Usted no puede evitar las necesidades cambiantes de los usuarios, las condiciones cambiantes del negocio, la naturaleza cambiante de los datos que se dan para trabajar, y el cambio tcnico ambiente. As que tal vez el juego de almacenamiento de datos es algo as como el juego de ajedrez. Al menos es una metfora bastante buena. Si tiene la intencin de leer este libro, usted necesita leer este captulo. Somos bastante precisa en este libro con nuestro vocabulario, y obtendr mejor este libro si usted sabe dnde estamos. Comenzamos con una breve definicin de los elementos bsicos del almacenamiento de datos. Como hemos comentado en la introduccin, no existe un acuerdo universal en el mercado sobre estas definiciones. Pero el uso de estas palabras es lo ms cercano a la prctica general como podemos hacerlos. Aqu, en este libro, vamos a utilizar estas palabras con precisin y coherencia, de acuerdo con las definiciones que ofrecemos en la siguiente seccin. A continuacin, se enumeran los procesos de almacn de datos que necesita para estar preocupados. Esta lista es una declaracin de los lmites de su puesto de trabajo. Tal vez el mayor conocimiento de sus responsabilidades como un conjunto de datos como gerente de almacn de datos es que esta lista de datos de los procesos de almacnes es largo y difcil en cierta medida.

Elementos bsicos de Data Warehouse

A medida que lea las definiciones en esta seccin, por favor refirase a la Figura 1.1. Lo haremos moverse a travs de la figura 1.1 ms o menos en orden de izquierda a derecha.

Fuente System
Un sistema operativo de registro, cuya funcin es capturar las transacciones del negocio. Un sistema de origen a menudo se llama un "sistema antiguo", en un entorno de mainframe. Las principales prioridades del sistema de origen son el tiempo de actividad y disponibilidad. Las consultas en sistemas de origen son estrechas ", basado en cuenta" las consultas que forman parte del proceso normal de transaccin de flujo y severamente restringidos en sus demandas sobre el sistema heredado. Nosotros asumir que los sistemas de origen mantienen pocos datos

histricos y de gestin que presentacin de informes de los sistemas de origen es una carga para estos sistemas. Hacemos el fuerte supuesto de que los sistemas de origen no se consultan en los caminos anchos e inesperado que los almacenes de datos se suelen consultar. Tambin suponemos que cada sistema fuente es un tubo de estufa natural, donde la inversin poco o nada se ha hecho para cumplir bsico dimensiones como producto, cliente, geografa, o el calendario con otro legado los sistemas de la organizacin. Sistemas de origen tienen las llaves que hacen ciertas cosas nicas, como las claves de producto o claves de los clientes. Nosotros llamamos a estas fuentes claves de teclas del sistema de produccin, y los tratamos como atributos, al igual que cualquier otra descripcin textual de algo. Nunca use las teclas de produccin como las claves en nuestro almacn de datos. (Espero que te llam la atencin. Lea los captulos sobre el modelado de datos.)

Datos de rea de ensayo

Un rea de almacenamiento y un conjunto de procesos que limpiar, transformar, combinar, de duplicar, hogar, archivar y preparar los datos de origen para su uso en el almacn de datos. El rea de preparacin de datos es todo lo que entre el sistema de origen y el servidor de presentacin. Aunque sera agradable si el rea de preparacin de datos fuera una sola instalacin centralizada en una sola pieza de hardware, es mucho ms probable que el rea de preparacin de datos se extiende sobre un nmero de mquinas. El rea de preparacin de datos est dominada por las actividades simples de la clasificacin y el tratamiento secuencial y, en algunos casos, el rea de almacenamiento de datos no necesita estar basado en la tecnologa relacional. Despus de revisar sus datos para lograr la conformidad con todos los uno-a-uno y muchos-a-uno las reglas de negocio que ha definido, puede ser intil para dar el ltimo paso de la construccin de un completo soplado entidad-relacin basada en el diseo de base de datos fsica. Sin embargo, hay muchos casos en que los datos llegan a las puertas de los datos el rea de almacenamiento en una base de datos relacional tercera forma normal. En otros casos, los directivos de la zona de concentracin de datos son ms cmodos organizando su limpieza, transformacin, y la combinacin de medidas en torno a un conjunto de estructuras normalizadas. En estos casos, una estructura normalizada para el almacenamiento de datos de ensayo es ciertamente aceptable. La restriccin de clave que define en el rea de preparacin de datos es que no proporciona los servicios de consulta y presentacin. Tan pronto como un sistema de consulta y proporciona servicios de presentacin, debe ser clasificado como un servidor de presentacin, que se describe a continuacin.

Presentation Server
El equipo de destino fsico en el que los datos de almacenamiento de datos se organiza y se almacena para consulta directa por los usuarios finales, redactores de informes, y otras aplicaciones. En nuestra opinin, tres sistemas muy diferentes son necesarios para un almacn de datos a la funcin: l sistema de origen, el rea de almacenamiento de datos, y el servidor de presentacin. El sistema de origen debe ser pensado como fuera del almacn de datos, ya que asumimos que no tenemos control sobre el contenido y formato

de los datos en el sistema anterior. Hemos descrito el rea de preparacin de datos como el almacenamiento inicial y sistema de limpieza para los datos que se est moviendo hacia el servidor de presentacin, y hemos hecho el punto de que los datos del rea de ensayo bien puede consistir en un sistema de archivos planos. Es el servidor de presentacin en el que insisten en que los datos se presenten y se almacenan en una estructura dimensional. Si el servidor de presentacin se basa en una base de datos relacional, las tablas se organizar como esquemas en estrella. Si el servidor de presentacin se basa en no relacional analtico en lnea (OLAP) la tecnologa, los datos todava tendr unas dimensiones reconocibles, y la mayora de las recomendaciones de este libro pertenecen a. En el momento de escribir este libro, la mayora de los mercados de datos de gran tamao (ms de unos pocos gigabytes) se aplicaron sobre bases de datos relacionales. As, la mayora de las discusiones especficas que rodean el servidor de presentacin se expresan en trminos de bases de datos relacionales.

Modelo Dimensional
Una disciplina especfica para el modelado de datos que es una alternativa a la entidad-relacin (E / R) modelado. Un modelo dimensional contiene la misma informacin que un modelo E / R pero los paquetes de datos en un formato cuyo diseo simtrico objetivos son: comprensibilidad del usuario, de las consultas y la resistencia al cambio. La justificacin para el modelado dimensional se presenta en el captulo 5. Este libro y su predecesor, The Data Warehouse Toolkit, se basan en la disciplina de modelado dimensional. Nosotros, los autores, estn comprometidos con este enfoque, ya hemos visto los almacenes de datos demasiados errores debido a demasiado complejas E / R diseos. Hemos empleado con xito las tcnicas de modelado dimensional en cientos de situaciones de diseo en los ltimos 15 aos. Los componentes principales de un modelo dimensional son las tablas de hechos y las tablas de dimensiones, que se definen cuidadosamente en el Captulo 5. Pero veamos brevemente. Una tabla de hechos es la tabla primaria en cada modelo dimensional que est destinado a contener las medidas de la empresa. A lo largo de este libro, siempre utilizar la palabra hecho de representar una medida comercial. Vamos a reducir la confusin terminolgica por no decir usingthe medida o medicin. Los hechos ms tiles son numricos y aditivo. Cada tabla de hechos representa una relacin muchos-a-muchos y cada tabla de hechos contiene un conjunto de dos o ms claves forneas que se unen a sus respectivas tablas de dimensiones. Una tabla de dimensiones es uno de un conjunto de tablas de compaa a una tabla de hechos. Cada dimensin es definida por su clave primaria que sirve como la base para la integridad referencial con cualquier tabla de hechos dada a la que est unida. La mayora de las tablas de dimensiones contienen muchos atributos de texto (campos) que son la base para limitar y agrupar dentro de las consultas de almacn de datos.

Business Process
Un conjunto coherente de actividades que tengan sentido para los usuarios de negocio de nuestros almacenes de datos. Esta definicin es deliberadamente un poco vaga. Un proceso de negocio es generalmente un conjunto de actividades como "procesamiento de pedidos" o "gestin de clientes gasoducto", pero los procesos de negocio pueden superponerse, y sin duda la definicin de un proceso de negocio individual ir evolucionando con el tiempo. En este libro, se supone que un proceso de negocio es un grupo de recursos de informacin til con un tema coherente. En muchos casos, vamos a implementar uno o ms mercados de datos para cada proceso de negocio.

Data Mart

Un subconjunto lgico del almacn de datos completa. Un data mart es un completo "pie de cua" del pastel de almacenamiento de datos en general. Un data mart representa un proyecto que puede ser llevado a su plenitud en lugar de ser una empresa imposible galctico. Un almacn de datos est formada por la unin de todos los data marts. Ms all de esta definicin lgica bastante simple, a menudo ver el mercado de datos como la restriccin del almacn de datos en un nico proceso de negocio o para un grupo de procesos de negocio relacionados dirigidos hacia un grupo empresarial en particular. El mercado de datos es, probablemente, patrocinado por y construido por una sola parte de la empresa, y un mercado de datos normalmente se organiza en torno a un nico proceso de negocio. Nos imponen unos requisitos de diseo muy especficos en cada puesto de datos. Cada puesto de datos debe estar representada por un modelo dimensional y, dentro de un almacn de datos nico, todos los data marts tales deben ser construidos a partir de dimensiones compatibles y hechos conformados. Esta es la base de la arquitectura de bus de almacenamiento de datos. Sin dimensiones compatibles y hechos conformados, un data mart es una copa. Stovepipes son la pesadilla de los movimientos de almacn de datos. Si usted tiene alguna esperanza de construir un almacn de datos que es robusto y resistente frente a las necesidades en constante evolucin, es necesario atenerse a la definicin de mercado de datos que recomendamos. Vamos a mostrar en este libro que, cuando los mercados de datos se han diseado con dimensiones compatibles y hechos conformados, que se pueden combinar y utilizar conjuntamente. (Lea ms sobre este tema en el Captulo 5.) No creemos que hay dos "en contraste con" puntos de vista sobre top-down vs bottom-up data warehouses. El extremo de arriba hacia abajo es que una perspectiva completamente base de datos centralizada, bien diseado maestro debe ser completado antes de algunas de sus partes se resumen y se publican en los mercados de datos individuales. El extremo de abajo hacia arriba perspectiva es que un almacn de datos empresarial puede ser montado a partir de mercados de datos dispares y sin relacin. Ni el enfoque adoptado a estos lmites es factible. En ambos casos, la nica solucin viable es una mezcla de los dos enfoques, en el que poner en prctica una arquitectura adecuada que gua el diseo de todas las piezas separadas. Cuando todas las piezas de todos los mercados de datos se desglosan a las distintas tablas fsicas en los servidores de bases de datos diferentes, ya que en ltima instancia debe ser, entonces la nica forma fsica para combinar los datos de estas tablas separadas y lograr una empresa integrada de almacenamiento de datos es si el dimensiones de los datos significan lo mismo en estas tablas. Nosotros llamamos a estas dimensiones compatibles. Esta arquitectura de almacenamiento de datos Bus es un motor fundamental de este libro. Por ltimo, no se adhieren a la definicin antigua data mart que un mercado de datos se compone de datos de resumen. Mercados de datos se basan en datos granulares y puede o no puede contener que aumentan el rendimiento resmenes, lo que llamamos "agregados" en este libro.

Data Warehouse
La fuente de datos consultable en la empresa. El almacn de datos no es ms que la unin de todos los data marts constituyentes. Un almacn de datos es alimentada desde el rea de almacenamiento de datos. El jefe de almacn de datos es responsable tanto para el almacn de datos y el rea de almacenamiento de datos.

Por favor, entienda que nosotros (y el mercado) se han apartado en un nmero de maneras de la definicin original del almacn de datos que data de principios de 1990. En concreto, el almacn de datos es el recurso presentacin consultable por un datos de la empresa y esta presentacin de recursos no debe ser organizada en torno a un modelo entityrelation porque, si se utiliza el modelado entidad-relacin, se perdern comprensibilidad y rendimiento. Adems, el almacn de datos se actualiza con frecuencia sobre una base de carga controlada cuando los datos se corrigen, las instantneas se acumulan, y los estados y las etiquetas se cambian. Por ltimo, el almacn de datos es precisamente la unin de sus mercados de datos constituyentes.

Operacional Data Store (ODS)

El trmino "almacn de datos operativos" ha tomado demasiadas definiciones que son tiles para el almacenamiento de datos. Hemos visto que este trmino se utiliza para describir todo, desde la base de datos que subyace en el sistema operativo para el almacenamiento de datos en s. Hay dos definiciones principales que vale la pena explorar en el contexto del almacn de datos. Originalmente, la SAO se ha creado para servir como punto de integracin para los sistemas operativos. Esto era especialmente importante para los sistemas de legado que crecieron independientes uno de otro. Los bancos, por ejemplo, solan tener varios sistemas independientes creados para soportar diferentes productos-prstamos, cuentas corrientes, cuentas de ahorro, etc. El advenimiento de las computadoras de apoyo cajeros ATM y la ayud a impulsar a muchos bancos a crear un almacn de datos operativos para integrar los saldos actuales y la historia reciente de estas cuentas separadas con el nmero uno cliente. Este tipo de bsqueda operativa es un ejemplo perfecto de la utilidad que una SAO puede jugar. De hecho, esta necesidad de integracin ha sido la fuerza impulsora detrs del xito de la empresa cliente / servidor ERP. Dado que este tipo de ODS necesita para apoyar el acceso constante operativa y actualizaciones, deben ser alojados fuera del almacn. Es decir, cualquier sistema estructurado para satisfacer necesidades operacionales y requisitos de rendimiento ser difcil satisfacer las necesidades de apoyo a las decisiones y los requisitos de rendimiento. Por ejemplo, usted no quiere a alguien para poner en marcha un modelo de calificacin complejo que requiere barridos completos de mesa y de agregacin de la historia del cliente, al mismo tiempo 1.000 representantes de telfonos catlogo estn tratando de ver el historial de clientes para apoyar una relacin de marketing one-to-one . Esto no sera bueno. En la segunda definicin, el propsito de la ODS se ha cambiado para incluir lo que suena como el acceso de soporte de decisiones por "empleados y ejecutivos." En este caso, la lgica parece enel que desde el ODS est destinada a contener los datos integrados en un nivel detallado, una shouldbuild para apoyar la capa ms baja de la bodega de datos. En nuestra opinin, estas dos definiciones son muy diferentes. El original ODS es un verdadero sistema operativo, independiente del almacn de datos, con diferentes niveles de requerimientos de servicio andperformance que deben cumplir. El segundo ODS es en realidad el tipo de borde delantero Ofthe de almacenamiento de datos que diseamos, realmente una parte del almacn de datos y no del sistema aseparate en absoluto. Si usted tiene un almacn de datos operativos en el entorno de sistemas, o en sus planes,

realice una inspeccin minuciosa. Si tiene la intencin de desempear un operativo en tiempo real, rol, entonces realmente es un almacn de datos operativos y debe tener su propio lugar en el mundo de los sistemas. Si, por otra parte, que est destinado a proporcionar informacin o apoyo a la decisin, le recomendamos que tome la SAO y satisfacer estas necesidades directamente desde el nivel de detalle del almacn de datos. Ofrecemos una discusin adicional sobre la inclusin de este nivel de detalle en el almacn en el Captulo 9.

OLAP (On-Line Analytic Processing)

La actividad general de consulta y presentacin de datos de texto y el nmero de almacenes de datos, as como un estilo especficamente dimensional de consulta y presentacin que se ejemplifica con una serie de "proveedores OLAP." La tecnologa OLAP vendedores "es relacional y se basa casi siempre en un cubo multidimensional explcita de los datos. Bases de datos OLAP tambin se conocen como bases de datos multidimensionales, o MDDBs. OLAP diseos de los vendedores de datos suelen ser muy similares a los diseos de los datos descritos en este libro, pero las instalaciones OLAP se clasifican como pequeas, marts de datos individuales cuando se ve contra toda la gama de aplicaciones de almacenamiento de datos. Creemos que OLAP de estilo mercados de datos pueden ser participantes plenos en el bus de almacenamiento de datos si estn diseados en torno a dimensiones compatibles y hechos conformados.

ROLAP (OLAP Relacional)

Un conjunto de interfaces de usuario y aplicaciones que dan una base de datos relacional un sabor dimensional. Este libro es altamente consistente con tanto ROLAP y MOLAP enfoques, aunque la mayor parte de los ejemplos especficos provienen de una perspectiva ROLAP.

MOLAP (OLAP multidimensional)

Un conjunto de interfaces de usuario, aplicaciones y tecnologas propietarias de bases de datos que tienen un sabor fuertemente dimensional.

Fin aplicacin de usuario

Informacin Una coleccin de herramientas que consultar, analizar y presentar dirigido a apoyar la necesidad de negocios. Un conjunto mnimo de herramientas tales consistira en una herramienta de usuario final de acceso a datos, una hoja de clculo, un paquete de grficos, y una instalacin de interfaz de

usuario para la obtencin de los mensajes y la simplificacin de las presentaciones en pantalla a los usuarios finales.

Datos de usuario final acceder a la Herramienta

Un cliente del almacn de datos. En un almacn de datos relacional, un cliente mantiene una sesin con el servidor de presentacin, el envo de un flujo de separadas peticiones SQL al servidor. Finalmente, el usuario final de datos herramienta de acceso se hace con la sesin de SQL y se vuelve a presentar una pantalla de datos o un informe, un grfico, o alguna otra forma superior de anlisis para el usuario. Un usuario final de datos herramienta de acceso puede ser tan simple como una herramienta de consulta ad hoc, o puede ser tan complejo como la minera de datos o aplicacin de modelado sofisticado. Algunas de las herramientas informticas ms sofisticadas de acceso como herramientas de modelado o prediccin en realidad puede subir sus resultados en las zonas especiales de almacenamiento de datos.

Ad Hoc Query Tool

Un tipo especfico de herramienta de usuario final acceso a datos que invita al usuario a crear sus propias consultas manipulando directamente las tablas relacionales y se une a su. Ad hoc herramientas de consulta, tan poderoso como es, slo puede ser efectivamente utilizado y comprendido por el 10 por ciento de todos los usuarios potenciales de un almacn de datos. El restante 90 por ciento de los usuarios potenciales deben ser servidos por pre-construidos aplicaciones que son mucho ms acabado "plantillas" que no requieren que el usuario final para construir una consulta relacional directamente. Las mejores herramientas ad hoc ROLAPoriented mejorar el nmero de 10 por ciento a quizs 20 por ciento.

Aplicaciones de Modelado
Un tipo de cliente sofisticado almacn de datos con capacidades analticas que transforman o digerir la salida del almacn de datos. Aplicaciones de modelado incluyen: Los modelos de pronstico que intentan predecir el futuro Los modelos de scoring de comportamiento que se agrupan y clasifican el comportamiento del cliente compra o comportamiento de los clientes de crdito Los modelos de asignacin que tienen datos sobre los costos del almacenamiento de datos y distribuir los costos a travs de grupos de productos o grupos de clientes La mayora de las herramientas de minera de datos

Metadatos
Toda la informacin en el medio de almacenamiento de datos que no son los datos reales s mismo. Tomamos una visin agresiva y expansiva de los metadatos en este libro. (Captulo 11) enumera todas las

formas de metadatos que se pueda imaginar y trata de darle un poco de orientacin sobre cmo reconocer, utilizar y metadatos control. Usted debe catalogar su metadata, versin estampar sus metadatos, documentar los metadatos, y copia de seguridad de los metadatos. Pero no espere que los metadatos se almacenan en una base de datos central. Hay demasiadas cosas que son metadatos, y sus formatos y usos son muy diversos.

Procesos bsicos del Data Warehouse

Puesta en escena de datos es un proceso mayor que incluye, entre otros, los siguientes subprocesos: extraccin, transformacin, carga e indexacin, y la comprobacin de control de calidad. Extraer. El paso de extraccin es el primer paso de la obtencin de datos en el almacn de datos ambiente. Utilizamos este trmino ms estrecha de lo que algunos consultores. Extrayendo significa la lectura y la comprensin de los datos de origen, y la copia de las partes que son necesaria para el rea de preparacin de datos para futuros trabajos. Transformar. Una vez que los datos se extraen en los datos del rea de ensayo, hay muchos medidas posibles de transformacin, incluyendo - Limpieza de los datos por corregir errores ortogrficos, la resolucin de conflictos de dominio (por ejemplo, una nombre de la ciudad que es incompatible con el cdigo postal), que trata de los datos faltantes elementos de anlisis, y en formatos estndar - Purga de campos seleccionados de los datos de legado que no son tiles para los datos del almacn - La combinacin de fuentes de datos, haciendo coincidir exactamente en los valores fundamentales o realizando borroso partidos en atributos no clave, incluyendo levantar equivalentes textuales de legado los cdigos del sistema - Creacin de claves de sustitucin para cada registro de dimensin con el fin de evitar una dependencia el legado de las claves definidas, en el proceso de generacin de claves sustituto hace cumplir integridad referencial entre las tablas de dimensiones y las tablas de hechos - Agregados de construccin para impulsar el rendimiento de las consultas comunes Carga e indexacin. Al final del proceso de transformacin, los datos estn en la forma de grabar imgenes de carga. Carga en el entorno de almacenamiento de datos por lo general toma la forma de replicar las tablas de dimensiones y tablas de hechos y la presentacin de estas tablas para las instalaciones de carga a granel de cada mercado destinatario de los datos. Granel de carga es una capacidad muy importante que ha de ser contrastado con la carga de registro-en-un-tiempo, que es mucho ms lento. La bolsa de datos de destino debe entonces indexar los datos recin llegados de rendimiento de la consulta, si no lo ha hecho ya. Aseguramiento de la Calidad de cheques. Cuando cada puesto de datos se ha cargado e indexado y se suministra con los agregados correspondientes, el ltimo paso antes de la publicacin es el paso de control de calidad. La garanta de calidad se puede comprobar mediante la ejecucin de un informe de excepcin global sobre el conjunto completo de datos recin cargadas. Todas las categoras de informacin debe estar

presente, y todos los recuentos y totales deben ser satisfactoria. Todos los valores presentados deben ser coherentes con las series temporales de valores similares que los precedieron. El informe de excepcin es, probablemente, construido con facilidad el mercado de datos del usuario final redaccin del informe. Publicacin / Editorial. Cuando cada puesto de datos ha sido recin cargado y calidad asegurado, la comunidad de usuarios debe ser notificado de que los nuevos datos est listo. Publicacin tambin se comunica la naturaleza de los cambios que se han producido en el subyacente dimensiones y supuestos nuevos que se han introducido en la medida o calculado hechos. Actualizado. En contra de la religin original del almacn de datos, datos modernos marts , bien puede ser actualizada, a veces con frecuencia. Datos incorrectos, obviamente, debe ser corregida. Los cambios en las etiquetas, los cambios en las jerarquas, los cambios de estado y cambios en la propiedad de las empresas a menudo desencadenar los cambios necesarios en los datos originales almacenados en los mercados de datos que componen el almacn de datos, pero en general se trata de "actualizaciones de administracin de carga", no actualizaciones transaccionales .

Realizar consultas. Consulta es un trmino amplio que abarca todas las actividades de su inters datos de un data mart, incluyendo consultas ad hoc por los usuarios finales, redaccin de informes, aplicaciones complejas de apoyo a las decisiones, las solicitudes de modelos y de pleno derecho de minera de datos. Consultar nunca se lleva a cabo en el rea de preparacin de datos. Por definicin, la consulta tiene lugar en un servidor de presentacin de almacn de datos. Consulta, obviamente, es el punto de utilizar el almacn de datos. Data Feedback / alimentacin a la inversa. Hay dos lugares importantes donde los datos fluye "hacia arriba" en la direccin opuesta a la corriente tradicional que hemos discutido en esta seccin. En primer lugar, puede cargar una descripcin dimensin limpiado del rea de preparacin de datos a un sistema heredado. Esto es deseable cuando el sistema heredado reconoce el valor de los datos mejorados. En segundo lugar, podemos cargar los resultados de una consulta compleja o una carrera de modelo o un anlisis de minera de datos de nuevo en un mercado de datos. Esta sera una forma natural para capturar el valor de una consulta compleja que toma la forma de filas y columnas que el usuario desea guardar.

Auditora. A veces es muy importante saber dnde estn los datos provienen de y cules fueron los clculos realizados. En el captulo 6, se discute una tcnica para la creacin de registros especiales de auditora durante las etapas de extraccin y transformacin en el rea de almacenamiento de datos. Estos registros de auditora estn vinculados directamente a los datos reales de tal manera que un usuario puede pedir el registro de auditora (el linaje) de los datos en cualquier momento. Proteger. Cada almacn de datos tiene un exquisito dilema: la necesidad de publicar la datos ampliamente a tantos usuarios como sea posible con fcil de utilizar las interfaces, pero al mismo tiempo proteger los datos sensibles valiosos de hackers, fisgones, e industriales espas. El desarrollo de Internet ha amplificado drsticamente este dilema. El equipo de almacenamiento de datos deben incluir ahora un nuevo miembro superior: el arquitecto de almacenamiento de datos de seguridad. Almacn de datos de seguridad debe ser gestionado de forma centralizada, desde una nica consola.

Los usuarios deben poder acceder a todos los mercados de datos que constituyen el almacn de datos con un inicio de sesin nico. En el captulo 12, se presenta una discusin a fondo de las cuestiones de seguridad en el almacenamiento de datos y lo que debe hacer al respecto. Realizar copias de seguridad y recuperacin. Puesto que los datos de almacenamiento de datos es un flujo de datos de la sistemas heredados a travs de los mercados de datos y, finalmente, en los escritorios de los usuarios, una verdadera pregunta surge acerca de dnde tomar las instantneas necesarias de los datos para fines de archivo y recuperacin de desastres. Adicionalmente, puede ser an ms complicado realizar una copia de seguridad y recuperacin de todos los metadatos que engrasa las ruedas de la operacin de almacenamiento de datos. En el captulo 9, se discuten los distintos tipos de actividades de copia de seguridad, y lo que un realista operacin de recuperacin supondra.

Los Grandes Debates Data Warehouse (The Big Data Warehouse Debates)
En el momento de escribir este libro, el mercado de almacn de datos est en el medio de una serie de cambios evolutivos. Como industria, tenemos miles de trabajar data marts y data warehouses en nuestro haber. Ahora tenemos que revisar algunos de los supuestos originales y las restricciones impuestas a nosotros mismos a finales de 1980 y principios de 1990. Y por supuesto, tenemos una tecnologa muy diferente a trabajar con ellos. A principios de 1998, 10.000 dlares podra comprar una mquina con dos procesadores de 300 MHz, 512 MB de memoria de acceso aleatorio, y 50 GB de disco duro rpido. Esta mquina puede sentarse en un sistema rpido de Ethernet y ejecutar cualquiera de las bases de datos relacionales importantes, incluso DB2. Aunque muchos mercados de datos necesita una mquina ms grande que esto, uno se pregunta si los data marts terabyte en las mquinas de clase de PC estn a la vuelta de la esquina. Al mismo tiempo, el mercado de almacenamiento de datos ha reaccionado con firmeza a la dificultad de planificacin y ejecucin de un nico e indiferenciado, maestro de almacenamiento de datos para el conjunto de la empresa. Este trabajo es demasiado abrumador para la mayora de las organizaciones y la mayora diseadores mortales incluso pensar. El futuro del almacenamiento de datos es modular, de bajo costo, diseado de forma incremental, distribuido data marts. La tecnologa de almacenamiento de datos ser una mezcla rica de gran mquinas monolticas que moler a travs de conjuntos de datos masivos con procesamiento paralelo, junto con muchas pequeas mquinas separadas (es decir, tal vez slo data marts terabyte!) mordisqueando en los conjuntos de datos individuales que pueden ser granular, ligeramente agregada, o altamente agregada. Los equipos independientes ser atado junto con el software de navegador que servir de cuadros para el envo de consultas a los servidores con mayor capacidad de respuesta. El futuro del almacenamiento de datos est en avances de software y la disciplina del diseo. Aunque las mquinas ms grandes continuarn a ser incluso ms eficaz en el procesamiento en paralelo, las mquinas ms pequeas ser proporcionalmente ms potente debido a los avances de hardware. Las mayores ganancias en el rendimiento, potencia de anlisis, y la eficacia de interfaz de usuario, sin embargo, vendr de mejores algoritmos y el endurecimiento de datos, diseos ms predecibles. Al adherirse

a la disciplina de modelado dimensional, un almacn de datos estar en una posicin mucho mejor para montar los avances que se realizan en la tecnologa de base de datos de software. En el momento de escribir estas lneas, las discusiones ms visibles en el almacenamiento de datos incluy los temas que aparecen en la siguiente seccin. No vamos a desarrollar los argumentos de pleno derecho en este captulo, pero tomamos nuestras posiciones resumen claro.

Data Warehouse Modeling

Como ya hemos comentado varias veces, creemos firmemente en el modelado dimensional para la fase de presentacin del almacn de datos. Captulo 5 conduce con un detallado justificacin para este enfoque. Para resumir, el modelado dimensional se debe utilizar en todos los servidores de la presentacin de un almacn de datos, ya que, en comparacin con el de entidad-relacin (E / R) 1. 9 modelado, este enfoque produce diseos predecibles y comprensibles que los usuarios pueden utilizar y asimilar y que se puede consultar con un alto rendimiento. Comprensibilidad y rendimiento son los requisitos individuales, no negociables del almacn de datos. La enfoque dimensional, a diferencia del enfoque E / R, no requiere la base de datos sea reestructurado o las consultas que ser reescrito cuando los nuevos datos se introduce en la almacn o cuando las relaciones entre los elementos de datos deben ser revisados. La mercado de datos dimensional, a diferencia de la mart E / R de datos, no es necesario anticipar el usuario consultas y es muy resistente a los cambios en los patrones de anlisis del usuario.

Data Marts y almacenes de datos

De nuevo, como ya se ha descrito, el almacn de datos es nada ms que la unin de sus mercados de datos constituyentes. Estos data marts evitar congestionamientos ser al ser organizado en torno a una arquitectura de bus dimensiones compatibles y hechos conformados. La tarea principal de datos para el diseo de la plantilla del almacn de datos es la identificacin y el establecimiento de estos dimensiones compatibles y hechos. El punto de vista opuesto, que no estamos de acuerdo con, es que el almacn de datos es un nonqueryable, E / R tienda estructurada y centralizada de datos y que data marts son disjuntos y resumen incompleto del almacn de datos central que se escindi cuando los usuarios demandan un tipo particular de anlisis. Como nota histrica, la idea de que un almacn de datos se pueden construir de forma incremental a partir de una serie de mercados de datos con dimensiones compatibles se describen detalladamente por Ralph Kimball en un artculo de la revista DBMS en agosto de 1996. Otras descripciones de esta tcnica, en particular el "Enterprise Data Mart Arquitectura" con "dimensiones comunes" y "hechos comunes" aparecido en la literatura un ao ms tarde. Estas descripciones son prcticamente idnticas a Trabajo Kimball. Los trminos originales "dimensiones compatibles" y "hechos" fueron conformadas descrito por la investigacin de mercados Nielsen a Ralph Kimball en 1984, y se refiri a Prctica de Nielsen en ese momento de unir datos sindicados de escner con los clientes ' los envos de datos internas. Los trminos "dimensin" y "hecho" se origin a partir de los desarrollos realizado conjuntamente por General Mills y la Universidad de Dartmouth en finales de 1960. Es evidente que estas ideas para combinar los data marts se haba inventado e introducido en el mercado comercial mucho antes de la actual generacin de expertos de la industria y consultores, incluso si no los llaman data marts.

Distribuido en comparacin con almacenes de datos centralizadas

Nos parece que la suerte ha estado llegando desde hace algn tiempo en esta industria. La idea de que una almacn de datos de la organizacin se apoya en un nico y centralizado de clase mainframe mquina es tan realista como la idea de 1950 que slo necesita un ordenador en un organizacin. A nivel de la computacin personal, ya tenemos decenas de miles de computadoras de grandes organizaciones. El almacn de datos ya estn siguiendo su ejemplo. Futuro almacenes de datos consistir en decenas o cientos de mquinas independientes con una amplia diferentes sistemas operativos y sistemas de bases de datos ampliamente diferentes, incluyendo todas las variantes de OLAP. Si se disean correctamente, estas mquinas comparten una arquitectura uniforme de dimensiones compatibles y hechos conformado que les permitan ser fusionados en un todo coherente. Creemos que estos dos ltimos temas, a saber, los almacenes de datos consistentes de muchos datos marts y almacenes de datos empresariales es un sistema distribuido, se fusionan en una vista arquitectnico. Este punto de vista permite que tanto el "hub and spoke" vista de un almacn de datos global, as como una vista totalmente distribuida de la bodega. No lo hacemos en ninguna manera se oponen a la idea de una mquina monoltica grande en el medio de un conjunto de datos almacn operacin. Algunas organizaciones encontrarn que esto tiene ms sentido para ellos. Dentro de esa mquina monoltica habr cientos de tablas, organizadas por tema reas. Vamos a llamar a estos grupos de tablas "data marts", y que slo funcionar como un todo sin fisuras si poseen dimensiones compatibles.

Resumen
Hemos definido todas las partes del entorno de almacenamiento de datos que se muestran en la Figura 1,1, y hemos descrito la forma en que trabajamos juntos. Hemos tratado brevemente las grandes discusiones teniendo lugar en la industria de almacenamiento de datos en la actualidad. En el prximo captulo es el momento de dirigir nuestra la atencin sobre el ciclo de vida de negocios Dimensional, que es el marco para el resto de la libro.