Data Warehousing: Proyecto

Data Warehousing-Realización de un proyecto

1. Organización

La planificación es el proceso más importante que determina la clase de tipo de estrategias data warehousing que una organización iniciará.

1.1 Factores en la Planificacion de un Data Warehouse

No existe una fórmula de garantía real para el éxito de la construcción de un data warehouse, pero hay muchos puntos que contribuyen a ese objetivo.

A continuación, se indican algunos puntos claves que deben considerarse en la planificación de un data warehouse:

Establecer una asociación de usuarios, gestión y grupos

Es esencial involucrar tanto a los usuarios como a la gestión para asegurar que el data warehouse contenga información que satisfaga los requerimientos de la empresa.

La gestión puede ayudar a priorizar la fase de la implementación del data warehouse, así como también la selección de herramientas del usuario. Los usuarios y la gestión justifican los costos del data warehouse sobre cómo será "su ambiente" y está basado primero en lo esperado y segundo, en el valor comercial real.

Seleccionar una aplicación piloto con una alta probabilidad de éxito

Una aplicación piloto de alcance limitado, con un reembolso medible para los usuarios y la gestión, establecerá el data warehouse como una tecnología clave para la empresa. Estos mismos criterios (alcance limitado, reembolso medible y beneficios claros para la empresa) se aplican a cada fase de la implementación de un data warehouse.

Construir prototipos rápida y frecuentemente

La única manera para asegurar que el data warehouse reúna las necesidades de los usuarios, es hacer el prototipo a lo largo del proceso de implementación y aún más allá, así como agregar los nuevos datos y/o los modelos en forma permanente. El trabajo continuo con los usuarios y la gestión es, nuevamente, la clave.

Implementación incremental

La implementación incremental reduce riesgos y asegura que el tamaño del proyecto permanezca manejable en cada fase.

Reportar activamente y publicar los casos exitosos

La retroalimentación de los usuarios ofrece una excelente oportunidad para publicar los hechos exitosos dentro de una organización. La publicidad interna sobre cómo el data warehouse ha ayudado a los usuarios a operar más efectivamente puede apoyar la construcción del data warehouse a lo largo de una empresa.

La retroalimentación del usuario también ayuda a comprender cómo evoluciona la implementación del data warehouse a través del tiempo para reunir requerimientos de usuario nuevamente identificados.

1.2 Estrategias para el Desarrollo de un Data Warehouse

Antes de desarrollar un data warehouse, es crítico el desarrollo de una estrategia equilibrada que sea apropiada para sus necesidades y sus usuarios.

Las preguntas que deben tenerse en cuenta son:

• ¿Quién es el auditorio?
• ¿Cuál es el alcance?
• ¿Qué tipo de data warehouse debería construirse?

Existe un número de estrategias mediante las cuales las organizaciones pueden conseguir sus data warehouses.

Primera

Establecer un ambiente "data warehouse virtual", el cual puede ser creado por:

• Instalación de un conjunto de facilidades para acceso a datos, directorio de datos y gestión de proceso.
• Entrenamiento de usuarios finales.
• Control de cómo se usan realmente las instalaciones del data warehouse.
• Basados en el uso actual, crear un data warehouse físico para soportar los pedidos de alta frecuencia.

Segunda

Construir una copia de los datos operacionales desde un sistema operacional único y posibilitar al data warehouse de una serie de herramientas de acceso a la información.

Esta estrategia tiene la ventaja de ser simple y rápida. Desafortunadamente, si los datos existentes son de mala calidad y/o el acceso a los datos no ha sido previamente evaluado, entonces se puede crear una serie de problemas.

Tercera

Finalmente, la estrategia data warehousing óptima es seleccionar el número de usuarios basados en el valor de la empresa y hacer un análisis de sus puntos, preguntas y necesidades de acceso a datos.

De acuerdo a estas necesidades, se construyen los prototipos data warehousing y se prueban para que los usuarios finales puedan experimentar y modificar sus requerimientos.

Una vez se tenga un consenso general sobre las necesidades, entonces se consiguen los datos provenientes de los sistemas operacionales existentes a través de la empresa y/o desde fuentes externas de datos y se cargan al data warehouse.

Si se requieren herramientas de acceso a la información, se puede también permitir a los usuarios finales tener acceso a los datos requeridos usando sus herramientas favoritas propias, o facilitar la creación de sistemas de acceso a la información multidimensional de alta performance, usando el núcleo del data warehouse como base.

En conclusión

No se tiene un enfoque único para construir un data warehouse que se adapte a las necesidades de las empresas, debido a que las necesidades de cada una de ellas son diferentes, al igual que su contexto.

Además, como la tecnología data warehousing va evolucionando, se aprende cada vez más y más sobre el desarrollo de data warehouses, que resulta en que el único enfoque práctico para al almacenamiento de datos es la evolución de uno mismo.

1.3 Estrategias para el Diseño de un Data Warehouse

El diseño de los data warehouses es muy diferente al diseño de los sistemas operacionales tradicionales. Se pueden considerar los siguientes puntos:

1. Los usuarios de los data warehouses usualmente no conocen mucho sobre sus requerimientos y necesidades como los usuarios operacionales.
2. El diseño de un data warehouse, con frecuencia involucra lo que se piensa en términos más amplios y con conceptos del negocio más difíciles de definir que en el diseño de un sistema operacional. Al respecto, un data warehouse está bastante cerca a Reingeniería de los Procesos del Negocio (Business Process Reengineering).
3. Finalmente, la estrategia de diseño ideal para un data warehousing es generalmente de afuera hacia adentro (outside-in) a diferencia de arriba hacia abajo (top-down).

A pesar que el diseño del data warehouse es diferente al usado en los diseños tradicionales, no es menos importante. El hecho que los usuarios finales tengan dificultad en definir lo que ellos necesitan, no lo hace menos necesario. En la práctica, los diseñadores de data warehouses tienen que usar muchos "trucos" para ayudar a sus usuarios a "visualizar" sus requerimientos. Por ello, son esenciales los prototipos de trabajo.

1.4 Estrategias para la Gestion de un Data Warehouse

Los data warehouses requieren una comercialización y gestión muy cuidadosa. Debe considerarse lo siguiente:

1. Un data warehouse es una inversión buena sólo si los usuarios finales realmente pueden conseguir información vital más rápida y más barata de lo que obtienen con la tecnología actual.
   Como consecuencia, la gestión tiene que pensarse seriamente sobre cómo quieren sus depósitos para su eficaz desempeño y cómo conseguirán llegar a los usuarios finales.
2. La administración debe reconocer que el mantenimiento de la estructura del data warehouse es tan crítico como el mantenimiento de cualquier otra aplicación de misión crítica.
   De hecho, la experiencia ha demostrado que los data warehouses llegarán a ser rápidamente uno de los sistemas más usados en cualquier organización.
3. La gestión debe comprender también que si se embarcan sobre un programa data warehousing, se crearán nuevas demandas sobre sus sistemas operacionales, que son:
   • Demandas para mejorar datos
   • Demandas para una data consistente
   • Demandas para diferentes tipos de datos, etc.

2 Desarrollo

2.1 ¿Porque Construir Bloques de Data Warehouse?

Para ampliar un negocio, se necesita que la información sea comprensible. Para muchas compañías, esto significa un gran data warehouse que muestre, junto a los datos no filtrados y dispersos, nuevas formas creativas de presentación.

Las herramientas para capturar y explorar los datos al detalle evolucionan, así como nuestra capacidad para encontrar las formas de explotar los datos recolectados.

En los últimos 10 años se han combinado dos factores para ayudar a la difusión de los data warehouses. Ellos son:

1. Se ha reconocido los beneficios del procesamiento analítico en línea (On Line Analytical Processing - OLAP), más allá de las áreas tradicionales de marketing y finanzas.
   Las organizaciones saben que los conocimientos inmersos en las masas de datos que rutinariamente recogen sobre sus clientes, productos, operaciones y actividades comerciales, contribuyen a reducir los costos de operación y aumentar las rentas, por no mencionar que es más fácil la toma de decisiones estratégicas.
2. El crecimiento de la computación cliente/servidor, ha creado servidores de hardware y software más poderosos y sofisticados que nunca. Los servidores de hoy compiten con las mainframes de ayer y ofrecen arquitecturas de memoria tecnológicamente superiores, procesadores de alta velocidad y capacidades de almacenamiento masivas.
   Al mismo tiempo, los Sistemas de Gestión de Base de Datos (Data Base Management Systems - DBMS(s)) modernos, proporcionan mayor soporte para las estructuras de datos complejas.
   De esta renovación de hardware y software surgen los data warehouses multiterabyte que ahora se ve en ambientes de cliente/servidor.

2.2 Consideraciones Previas al Desarrollo de un Data Warehouse

Hay muchas maneras para desarrollar data warehouses como tantas organizaciones existen. Sin embargo, hay un número de dimensiones diferentes que necesitan ser consideradas:

• Alcance de un data warehouse
• Redundancia de datos
• Tipo de usuario final

La Figura N° 15 muestra un esquema bidimensional para analizar las opciones básicas. La dimensión horizontal indica el alcance del depósito y la vertical muestra la cantidad de datos redundantes que deben almacenarse y mantenerse.

2.2.1 Alcance des Data Warehouse

El alcance de un data warehouse puede ser tan amplio como toda la información estratégica de la empresa desde su inicio, o puede ser tan limitado como un data warehouse personal para un solo gerente durante un año.

En la práctica, en la amplitud del alcance, el mayor valor del data warehouse es para la empresa y lo más caro y consumidor de tiempo es crear y mantenerlo. Como consecuencia de ello, la mayoría de las organizaciones comienzan con data warehouses funcionales, departamentales o divisionales y luego los expanden como usuarios que proveen retroalimentación.

2.2.2 Redundancia de Datos

Hay tres niveles esenciales de redundancia de datos que las empresas deberían considerar en sus opciones de data warehouse:

• Data warehouses "virtual" o "Point to Point"
• Data warehouses "centrales"
• Data warehouses "distribuidos"

No se puede pensar en un único enfoque. Cada opción adapta un conjunto específico de requerimientos y una buena estrategia de almacenamiento de datos, lo constituye la inclusión de las tres opciones.

Data Warehouses "Virtual" o "Point to Point"

Una estrategia de data warehouses virtual, significa que los usuarios finales pueden acceder a bases de datos operacionales directamente, usando cualquier herramienta que posibilite "la red de acceso de datos".

Este enfoque provee flexibilidad así como también la cantidad mínima de datos redundantes que deben cargarse y mantenerse. Además, se pueden colocar las cargas de consulta no planificadas más grandes, sobre sistemas operacionales.

Como se verá, el almacenamiento virtual es, frecuentemente, una estrategia inicial, en organizaciones donde hay una amplia (pero en su mayor parte indefinida) necesidad de conseguir la data operacional, desde una clase relativamente grande de usuarios finales y donde la frecuencia probable de pedidos es baja.

Los depósitos virtuales de datos proveen un punto de partida para que las organizaciones determinen qué usuarios finales están buscando realmente.

Data Warehouses "Centrales"

El concepto de data warehouses centrales es el concepto inicial que se tiene del data warehouse. Es una única base de datos física, que contiene todos los datos para un área funcional específica, departamento, división o empresa.

Los data warehouses centrales se seleccionan por lo general donde hay una necesidad común de los datos informáticos y un número grande de usuarios finales ya conectados a una red o computadora central. Pueden contener datos para cualquier período específico de tiempo. Comúnmente, contienen datos de sistemas operacionales múltiples.

Los data warehouses centrales son reales. Los datos almacenados en el data warehouse son accesibles desde un lugar y deben cargarse y mantenerse sobre una base regular. Normalmente se construyen alrededor de RDBMS avanzados o, en alguna forma, de servidor de base de datos informático multidimensional.

Data Warehouses Distribuidos

Los data warehouses distribuidos son aquellos en los cuales ciertos componentes del depósito se distribuyen a través de un número de bases de datos físicas diferentes.

Cada vez más, las organizaciones grandes están tomando decisiones a niveles más inferiores de la organización y a la vez, llevando los datos que se necesitan para la toma de decisiones a la red de área local (Local Area Network - LAN) o computadora local que sirve al que toma decisiones.

Los data warehouses distribuidos comúnmente involucran la mayoría de los datos redundantes y como consecuencia de ello, se tienen procesos de actualización y carga más complejos.

2.2.3 Tipo de Usuario Final

De la misma forma que hay una gran cantidad de maneras para organizar un data warehouse, es importante notar que también hay una gama cada vez más amplia de usuarios finales.

En general, se puede considerar tres grandes categorías:

• Ejecutivos y gerentes
• "Power users" o "Buzo de Información" (analistas financieros y de negocios, ingenieros, etc.)
• Usuarios de soporte (de oficina, administrativos, etc.).

Cada una de estas categorías diferentes de usuario tienen su propio conjunto de requerimientos para los datos, acceso, flexibilidad y facilidad de uso.

2.3 Elementos Claves para el Desarrollo de un Data Warehouse

Los data warehouses exitosos comienzan cuando se escogen e integran satisfactoriamente tres elementos claves.

Un data warehouse está integrado por un servidor de hardware y los DBMS que conforman el depósito. Del lado del hardware, se debe combinar la configuración de plataformas de los servidores, mientras se decide cómo aprovechar los saltos casi constantes de la potencia del procesador. Del lado del software, la complejidad y el alto costo de los DBMSes fuerzan a tomar decisiones drásticas y balances comparativos inevitables, con respecto a la integración, requerimientos de soporte, desempeño, eficiencia y confiabilidad.

Si se escoge incorrectamente, el data warehouse se convierte en una gran empresa con problemas difíciles de trabajar en su entorno, costoso para arreglar y difícil de justificar.

Para conseguir que la implementación del depósito tenga un inicio exitoso, se necesita enfocar hacia tres bloques claves de construcción:

• Arquitectura total del depósito
• Arquitecturas del servidor
• Sistemas de Gestión de Base de Datos

A continuación se presentan algunas recomendaciones para tomar las correctas elecciones para su empresa.

2.3.1 Diseño de la Arquitectura

Arquitectura del Depósito

El desarrollo del data warehouse comienza con la estructura lógica y física de la base de datos del depósito más los servicios requeridos para operar y mantenerlo. Esta elección conduce a la selección de otros dos ítems fundamentales: el servidor de hardware y el DBMS.

La plataforma física puede centralizarse en una sola ubicación o distribuirse regional, nacional o internacionalmente. A continuación se dan las siguientes alternativas de arquitectura:

1. Un plan para almacenar los datos de su compañía, que podría obtenerse desde fuentes múltiples internas y externas, es consolidar la base de datos en un data warehouse integrado. El enfoque consolidado proporciona eficiencia tanto en la potencia de procesamiento como en los costos de soporte. (Ver Figura N° 16).
   
2. La arquitectura global distribuye información por función, con datos financieros sobre un servidor en un sitio, los datos de comercialización en otro y los datos de fabricación en un tercer lugar. (Ver Figura N° 17)
   
3. Una arquitectura por niveles almacena datos altamente resumidos sobre una estación de trabajo del usuario, con resúmenes más detallados en un segundo servidor y la información más detallada en un tercero.
   La estación de trabajo del primer nivel maneja la mayoría de los pedidos para los datos, con pocos pedidos que pasan sucesivamente a los niveles 2 y 3 para la resolución.
   Las computadoras en el primer nivel pueden optimizarse para usuarios de carga pesada y volumen bajo de datos, mientras que los servidores de los otros niveles son más adecuados para procesar los volúmenes pesados de datos, pero cargas más livianas de usuario. (Ver figura N° 18).
   

Arquitectura del servidor

Al decidir sobre una estructura de depósito distribuida o centralizada, también se necesita considerar los servidores que retendrán y entregarán los datos. El tamaño de su implementación (y las necesidades de su empresa para escalabilidad, disponibilidad y gestión de sistemas) influirá en la elección de la arquitectura del servidor.

1° Servidores de un solo procesador

Los servidores de un sólo procesador son los más fáciles de administrar, pero ofrecen limitada potencia de procesamiento y escalabilidad. Además, un servidor sólo presenta un único punto de falla, limitando la disponibilidad garantizada del depósito.

Se puede ampliar un solo servidor de redes mediante arquitecturas distribuidas que hacen uso de subproductos, tales como Ambientes de Computación Distribuida (Distributed Computing Environment - DCE) o Arquitectura Broker de Objeto Común (Common Objects Request Broker Architecture - CORBA), para distribuir el tráfico a través de servidores múltiples.

Estas arquitecturas aumentan también la disponibilidad, debido a que las operaciones pueden cambiarse al servidor de copia de seguridad si un servidor falla, pero la gestión de sistemas es más compleja.

2° Multiprocesamiento simétrico

Las máquinas de multiprocesamiento simétrico (Symmetric MultiProcessing - SMP) aumentan mediante la adición de procesadores que comparten la memoria interna de los servidores y los dispositivos de almacenamiento de disco.

Se puede adquirir la mayoría de SMP en configuraciones mínimas (es decir, con dos procesadores) y levantar cuando es necesario, justificando el crecimiento con las necesidades de procesamiento. La escalabilidad de una máquina SMP alcanza su límite en el número máximo de procesadores soportados por los mecanismos de conexión (es decir, el backplane y bus compartido).

3° Procesamiento en paralelo masivo

Una máquina de procesamiento en paralelo masivo (Massively Parallel Processing - MPP), conecta un conjunto de procesadores por medio de un enlace de banda ancha y de alta velocidad. Cada nodo es un servidor, completo con su propio procesador (posiblemente SMP) y memoria interna. Para optimizar una arquitectura MPP, las aplicaciones deben ser "paralelizadas" es decir, diseñadas para operar por separado, en partes paralelas.

Esta arquitectura es ideal para la búsqueda de grandes bases de datos. Sin embargo, el DBMS que se selecciona debe ser uno que ofrezca una versión paralela. Y aún entonces, se requiere un diseño y afinamiento esenciales para obtener una óptima distribución de los datos y prevenir "hot spots" o "data skew" (donde una cantidad desproporcionada del procesamiento es cambiada a un nodo de procesamiento, debido a la partición de los datos bajo su control).

4° Acceso de memoria no uniforme

La dificultad de mover aplicaciones y los DBMS a agrupaciones o ambientes realmente paralelos ha conducido a nuevas y recientes arquitecturas, tales como el acceso de memoria no uniforme (Non Uniform Memory Access - NUMA).

NUMA crea una sola gran máquina SMP al conectar múltiples nodos SMP en un solo (aunque físicamente distribuida) banco de memoria y un ejemplo único de OS. NUMA facilita el enfoque SMP para obtener los beneficios de performance de las grandes máquinas MPP (con 32 o más procesadores), mientras se mantiene las ventajas de gestión y simplicidad de un ambiente SMP estándar.

Lo más importante de todo, es que existen DBMS y aplicaciones que pueden moverse desde un solo procesador o plataforma SMP a NUMA, sin modificaciones.

2.3.2 Sistemas de Gestión de Bases de Datos

Los data warehouses (conjuntamente con los sistemas de soporte de decisión [Decision Support Systems - DSS] y las aplicaciones cliente/servidor), fueron los primeros éxitos para el DBMS relacional (Relational Data Base Management Systems - RDBMS).

Mientras la gran parte de los sistemas operacionales fueron resultados de aplicaciones basadas en antiguas estructuras de datos, los depósitos y sistemas de soporte de decisiones aprovecharon el RDBMS por su flexibilidad y capacidad para efectuar consultas con un único objetivo concreto.

Los RDBMS son muy flexibles cuando se usan con una estructura de datos normalizada. En una base de datos normalizada, las estructuras de datos son no redundantes y representan las entidades básicas y las relaciones descritas por los datos (por ejemplo productos, comercio y transacción de ventas). Pero un procesamiento analítico en línea (OLAP) típico de consultas que involucra varias estructuras, requiere varias operaciones de unión para colocar los datos juntos.

La performance de los RDBMS tradicionales es mejor para consultas basadas en claves ("Encuentre cuenta de cliente #2014") que para consultas basadas en el contenido ("Encuentre a todos los clientes con un ingreso sobre $ 10,000 que hayan comprado un automóvil en los últimos seis meses").

Para el soporte de depósitos a gran escala y para mejorar el interés hacia las aplicaciones OLAP, los proveedores han añadido nuevas características al RDBMS tradicional. Estas, también llamadas características super relacionales, incluyen el soporte para hardware de base de datos especializada, tales como la máquina de base de datos Teradata.

Los modelos super relacionales también soportan extensiones para almacenar formatos y operaciones relacionales (ofrecidas por proveedores como REDBRICK) y diagramas de indexación especializados, tales como aquellos usados por SYBASE IQ. Estas técnicas pueden mejorar el rendimiento para las recuperaciones basadas en el contenido, al pre juntar tablas usando índices o mediante el uso de listas de índice totalmente invertidos.

Muchas de las herramientas de acceso a los data warehouses explotan la naturaleza multidimensional del data warehouse. Por ejemplo, los analistas de marketing necesitan buscar en los volúmenes de ventas por producto, por mercado, por período de tiempo, por promociones y niveles anunciados y por combinaciones de estos diferentes aspectos.

La estructura de los datos en una base de datos relacional tradicional, facilita consultas y análisis a lo largo de dimensiones diferentes que han llegado a ser comunes. Estos esquemas podrían usar tablas múltiples e indicadores para simular una estructura multidimensional. Algunos productos DBMS, tales como ESSBASE y GENTIUM, implementan técnicas de almacenamiento y operadores que soportan estructuras de datos multidimensionales.

Mientras las bases de datos multidimensionales (MultiDimensional Databases - MDDBs) ayudan directamente a manipular los objetos de datos multidimensionales (por ejemplo, la rotación fácil de los datos para verlos entre dimensiones diferentes, o las operaciones de drill down que sucesivamente exponen los niveles de datos más detallados), se debe identificar estas dimensiones cuando se construya la estructura de la base de datos. Así, agregar una nueva dimensión o cambiar las vistas deseadas, puede ser engorroso y costoso. Algunos MDDBS requieren un recargue completo de la base de datos cuando ocurre una reestructuración.

2.3.3 Nuevas Dimensiones

Una limitación de un RDBMS y un MDDB, es la carencia de soporte para tipos de datos no tradicionales como imágenes, documentos y clips de vídeo / audio. Si usted necesita estos tipos de objetos en su data warehouse, busque un DBMS relacional - objeto (Ejemplo: ILLUSTRA de INFORMIX).

Por su enfoque en los valores de datos codificados, la mayor parte de los sistemas de base de datos pueden acomodar estos tipos de datos, sólo con extensiones basadas en cierta referencias, tales como indicadores de archivos que contienen los objetos. Muchos RDBMS almacenan los datos complejos como objetos grandes binarios (Binary Large Objects - BLOBs). En este formato, los objetos no pueden ser indexados, clasificados, o buscados por el servidor.

Los DBMS relacional - objeto, de otro lado, almacenan los datos complejos como objetos nativos y pueden soportar las grandes estructuras de datos encontradas en un ambiente orientado a objetos. Estos sistemas de base de datos naturalmente acomodan no sólo tipos de datos especiales sino también los métodos de procesamiento que son únicos para cada uno de ellos.

Pero una desventaja del enfoque relacional - objeto, es que la encapsulación de los datos dentro de los tipos especiales de datos (una serie de precios de stock a través del tiempo en cada registro de una tabla de stock, por ejemplo), requiere de operadores especializados para que hagan búsquedas simples previamente (por ejemplo, "Encontrar todas las existencias que han mostrado una disminución en el precio de Abril a Mayo 1996").

La selección del DBMS está también sujeta al servidor de hardware que se usa. Algunos RDBMS, como el DB2 Paralelo, INFORMIX XPS y el ORACLE Paralelo, ofrecen versiones que soportan operaciones paralelas. El software paralelo divide consultas, uniones a través de procesadores múltiples y corre estas operaciones simultáneamente para mejorar la performance.

Se requiere el paralelismo para el mejor desempeño en los servidores MPP grandes y SMP agrupados. No es aún una opción con MDDBS o DBMS relacional - objeto.

En la tabla "Cómo comparar DBMS" se resume los pro y los contra de los diferentes tipos de DBMS para operaciones de data warehouse.

La tabla "Matriz de Decisión del Data Warehouse" contiene algunos ejemplos de cómo afectan estos criterios de decisión en la elección de una arquitectura de servidor/ data warehouse.

¿Cómo comparar DBMSES?
Características/Función	Relacional	Super Relacional	Multidimensional (Lógico)	Multidimensional (Físico)	Objeto Relacional
Estructuras Normalizadas
Tipos de datos abstractos
Paralelismo
Estructuras Multidimensionales
Drill-Down
Rotación
Operaciones dependientes de datos

Matriz de Decisión para el Data Warehouse
Para estos ambientes.			Elija.
Requerimientos comerciales	Usuarios	Soporte de Sistemas	Arquitectura	Servidor	DBMS
Alcance: departamental	Pequeña - ubicación única	Local mínimo - central promedio	Consolidado - paquete	Procesador único o SMP	MDDB
Usos: análisis de datos
Alcance: departamental	Grande Analistas en una sola ubicación; usuarios informáticos dispersos	Local mínimo - central promedio	Seccionado - detalle en central - resumen en local	Grupos de SMP para central; SP o SMP para local	RDBMS para central - MDDB para local
Usos: análisis más informática
Alcance: empresa	Grande; geográficamente disperso	Central fuerte	Centralizado	Grupos de SMP	Objeto-relacional- soporte Web
Usos: análisis más informática
Alcance: departamental	Pequeña - pocas ubicaciones	Central fuerte	Centralizado	MPP	RDBMS con soporte paralelo
Usos: investigación

2.3.4 Combinacion de la Arquitectura con el Sistema de Gestion de Bases de Datos

Para seleccionar la combinación correcta de la arquitectura del servidor y el DBMS, primero es necesario comprender los requerimientos comerciales de su compañía, su población de usuarios y las habilidades del personal de soporte.

Las implementaciones de los data warehouses varían apreciablemente de acuerdo al área. Algunos son diseñados para soportar las necesidades de análisis específico para un solo departamento o área funcional de una organización, tales como finanzas, ventas o marketing. Las otras implementaciones reúnen datos a través de toda la empresa para soportar una variedad de grupos de usuarios y funciones. Por regla general, a mayor área del depósito, se requiere mayor potencia y funcionalidad del servidor y el DBMS.

Los modelos de uso de los data warehouses son también un factor. Las consultas y vistas de reportes preestructuradas frecuentemente satisfacen a los usuarios informáticos, mientras que hay menos demandas sobre el DBMS y la potencia de procesamiento del servidor. El análisis complejo, que es típico de los ambientes de decisión - soporte, requiere más poder y flexibilidad de todos los componentes del servidor. Las búsquedas masivas de grandes data warehouses favorecen el paralelismo en el DBMS y el servidor.

Los ambientes dinámicos, con sus requerimientos siempre cambiantes, se adaptan mejor a una arquitectura de datos simple, fácilmente cambiable (por ejemplo, una estructura relacional altamente normalizada), antes que una estructura intrincada que requiere una reconstrucción después de cada cambio (por ejemplo, una estructura multidimensional).

El valor de la data fresca requerida indica cuán importante es para el data warehouse renovar y cambiar los datos. Los grandes volúmenes de datos que se refrescan a intervalos frecuentes, favorecen una arquitectura físicamente centralizada para soportar una captura de datos eficiente y minimizar el tiempo de transporte de los datos.

Un perfil de usuario debería identificar quiénes son los usuarios de su data warehouse, dónde se ubican y cuántos necesita soportar. La información sobre cómo cada grupo espera usar los data warehouses, ayudará a analizar los diversos estilos de uso.

Conocer la ubicación física de sus usuarios ayudará a determinar cómo y a qué área necesita distribuir el data warehouse. Una arquitectura por niveles podría usar servidores en el lugar de las redes de área local. O puede necesitar un enfoque centralizado para soportar a los trabajadores que se movilizan y que trabajan en el depósito desde sus laptops.

El número total de usuarios y sus modelos de conexión determinan el tamaño de sus servidores de depósito. Los tamaños de memoria y los canales de I/O deben soportar el número previsto de usuarios concurrentes bajo condiciones normales, así como también en las horas punta de su organización.

Finalmente, se debe factorizar la sofisticación del personal de soporte. Los recursos de los sistemas de información (Information System - IS) que están disponibles dentro de su organización, pueden limitar la complejidad o sofisticación de la arquitectura del servidor. Sin el personal especializado interno o consultores externos, es difícil de crear y mantener satisfactoriamente una arquitectura que requiere paralelismo en la plataforma del servidor (MPP o SMP agrupado, por ejemplo).

2.3.5 Planes de Expansion

Como su depósito evoluciona y los datos que contiene llegan a ser más accesible, los empleados externos al depósito podrían descubrir también el valor de sus datos. Al enlazar su data warehouse a otros sistemas (tanto internos como externos a la organización), se puede compartir información con otras entidades comerciales con poco o sin desarrollo. Los mensajes de correo electrónico, servidores WEB y conexiones Intranet/Internet, pueden entregar listas por niveles a sus proveedores o según su condición, a sus socios de negocio.

Como los data warehouses continúan creciendo en sofisticación y uso, los datos acumulados dentro de una empresa llegarán a ser más organizados, más interconectados, más accesibles y, en general, más disponibles a más empleados.

El resultado será la obtención de mejores decisiones en el negocio, más oportunidades y más claridad de trabajo.

2.4 Confiabilidad de los Datos

La data "sucia" es peligrosa. Las herramientas de limpieza especializadas y las formas de programar de los clientes proporcionan redes de seguridad.

No importa cómo esté diseñado un programa o cuán hábilmente se use. Si se alimenta mala información, se obtendrá resultados incorrectos o falsos. Desafortunadamente, los datos que se usan satisfactoriamente en las aplicaciones de línea comercial operacionales pueden ser basura en lo que concierne a la aplicación data warehousing.

Los datos "sucios" pueden presentarse al ingresar información en una entrada de datos (por ejemplo, "Sistemas S. A." en lugar de "Sistemas S. A.") o de otras causas. Cualquiera que sea, la data sucia daña la credibilidad de la implementación del depósito completo. A continuación, en la Figura N° 23 se muestra un ejemplo de formato de ventas en el que se pueden presentar errores.

Afortunadamente, las herramientas de limpieza de datos pueden ser de gran ayuda. En algunos casos, puede crearse un programa de limpieza efectivo. En el caso de bases de datos grandes, imprecisas e inconsistentes, el uso de las herramientas comerciales puede ser casi obligatorio.

Decidir qué herramienta usar es importante y no solamente para la integridad de los datos. Si se equivoca, se podría malgastar semanas en recursos de programación o cientos de miles de dólares en costos de herramientas.

La limpieza de una data "sucia" es un proceso multifacético y complejo. Los pasos a seguir son los siguientes:

1. Analizar sus datos corporativos para descubrir inexactitudes, anomalías y otros problemas.
2. Transformar los datos para asegurar que sean precisos y coherentes.
3. Asegurar la integridad referencial, que es la capacidad del data warehouse, para identificar correctamente al instante cada objeto del negocio, tales como un producto, un cliente o un empleado.
4. Validar los datos que usa la aplicación del data warehouse