5. DataMart

Un DataMart es la capa de acceso de los almacenes de datos medio que se utiliza para obtener datos de los usuarios. El mercado de datos es un subconjunto del almacén de datos que generalmente se orienta a una línea de negocio específica o equipo.

Terminología

No puede haber varios puestos de datos dentro de una sola corporación, cada uno correspondiente a una o más unidades de negocio para el cual fue diseñado. Mercados de datos puede o no puede ser dependiente o en relación con otros mercados de datos en una sola corporación. Si los mercados de datos se diseñan utilizando conformado hechos y dimensiones , entonces van a estar relacionados. En algunas implementaciones, cada unidad de negocio o departamento es considerado el dueño de su puesto de datos incluyendo todo el hardware, software y datos. Esto permite que cada departamento de usar, manipular y elaborar los datos de la forma que estimen conveniente, sin alterar la información dentro de los data marts otros o el almacén de datos. En otras implementaciones donde se utilizan dimensiones compatibles, esta unidad de negocios de propiedad no son válidas para las dimensiones comunes, como cliente, producto, etc
El término relacionado spreadmart describe la situación que se produce cuando uno o más analistas de negocio desarrollar un sistema de valores vinculados a las hojas de cálculo para realizar un análisis del negocio, entonces crecer a un tamaño y grado de complejidad que hace que sea casi imposible de mantener.

Esquemas de diseño

• Esquema de estrella o de un modelo tridimensional es una opción de diseño muy popular, ya que permite una base de datos relacional para emular la funcionalidad de análisis de una base de datos multidimensional .
• Copo de nieve esquema
• Datamart Arquitectura del patrón (EA arquitectura de referencia)

Razones para la creación de un data mart

• Fácil acceso a los datos requeridos frecuentemente
• Crea opinión colectiva de un grupo de usuarios
• Mejora para el usuario final el tiempo de respuesta
• Facilidad de creación
• Un costo menor que la implementación de un completo almacén de datos
• Los usuarios potenciales están más claramente definidas que en un almacén de datos completo

Data mart dependiente

De acuerdo con Inmon escuela de almacenamiento de datos, un data mart dependiente es un subconjunto lógico ( vista ) o un subconjunto físico (extracto) de un gran almacén de datos , aislados por una de las siguientes razones:

• Un refresco necesidad de un especial modelo de datos o esquema : por ejemplo, la reestructuración de OLAP
• Rendimiento: para descargar el data mart a una por separado equipo para una mayor eficiencia o para obviar la necesidad de gestionar la carga de trabajo en el almacén de datos centralizado.
• Seguridad: para separar un subconjunto de datos autorizados de forma selectiva
• Oportunidad: para evitar el gobierno de datos y autorizaciones necesarias para incorporar una nueva aplicación en el almacén de datos empresariales
• Proving Ground: para demostrar la viabilidad y el ROI (retorno sobre la inversión) el potencial de una solicitud antes de que la migración a la Enterprise Data Warehouse
• La política: una estrategia de afrontamiento para TI (Tecnologías de la Información) en situaciones donde un grupo de usuarios tiene más influencia que los fondos o no es un buen ciudadano en el almacén de datos centralizado.
• La política: una estrategia de afrontamiento para los consumidores de datos en situaciones donde un equipo de almacenamiento de datos no es capaz de crear un almacén de datos utilizables.

De acuerdo con la escuela Inmon de almacenamiento de datos, ventajas y desventajas inherentes a los puestos de datos incluyen la escalabilidad limitada, la duplicación de datos, la inconsistencia de datos con otros silos de información, y la incapacidad para aprovechar las fuentes de la empresa de los datos.

2. Proceso de Negocio

Un proceso de negocio o un método de negocio es un conjunto de actividades relacionadas, estructurados o tareas que producen un determinado servicio o producto (alcanzar un objetivo particular) para un determinado cliente o clientes. A menudo puede ser visualizada con un diagrama de flujo como una secuencia de actividades con la intercalación de los puntos de decisión o con una matriz de procesos como una secuencia de actividades con las normas de relevancia en base a los datos en el proceso.

Información general

Hay tres tipos de procesos de negocio:

1. Los procesos de gestión , los procesos que rigen el funcionamiento de un sistema. Los procesos típicos de gestión incluyen el " Gobierno Corporativo "y" Gestión Estratégica ".
2. Procesos operativos , los procesos que constituyen el core business y crear la cadena de valor primaria. Típico de los procesos operativos están de compras , fabricación , publicidad y marketing y ventas .
3. Procesos de apoyo , que apoyan los procesos centrales. Los ejemplos incluyen contabilidad , contratación , centro de llamadas , soporte técnico .

Un proceso de negocio comienza con un objetivo de la misión y termina con la consecución de los objetivos de negocio. Orientados a los procesos las organizaciones romper las barreras estructurales de los departamentos y tratar de evitar los silos funcionales .
Un proceso de negocio se puede descomponer en varios sub-procesos , que tienen sus propios atributos, sino que también contribuyen a lograr el objetivo del proceso de super-. El análisis de los procesos de negocio por lo general incluye el mapeo de procesos y subprocesos, hasta el nivel de actividad.
Los procesos de negocios están diseñados para agregar valor para el cliente y no debe incluir actividades innecesarias. El resultado de un proceso de negocio bien diseñado es una mayor eficacia (valor para el cliente) y el aumento de la eficiencia (menos costes para la empresa).
Los procesos de negocio pueden modelarse a través de un gran número de métodos y técnicas. Por ejemplo, el Business Process Modeling Notation es un modelado de procesos de negocio técnica que puede ser utilizado para la elaboración de procesos de negocio en un flujo de trabajo .

Importancia de la cadena del proceso

Los procesos de negocio comprenden una serie secuencial de sub-procesos o tareas, con rutas alternativas en función de determinadas condiciones, en su caso, realiza para lograr un objetivo determinado o producir resultados da. Cada proceso tiene uno o más insumos necesarios. Las entradas y salidas pueden ser recibidos o enviados a otros procesos de negocio, otras unidades organizativas o grupos de interés internos o externos.
Los procesos de negocios están diseñados para ser operados por una o más unidades funcionales de la empresa, y hacer hincapié en la importancia de la "cadena de procesos" en lugar de las unidades individuales.
En general, las diversas tareas de un proceso de negocio se puede realizar en una de dos maneras:
1) de forma manual y
2) por medio de los datos de los sistemas de procesamiento de negocios tales como los sistemas ERP. Por lo general, algunas de las tareas proceso será manual, mientras que otras serán basados ​​en computadoras, y estas tareas pueden ser secuenciados de muchas maneras. En otras palabras, los datos y la información que se maneja a través del proceso puede pasar a través de tareas manuales o de un ordenador en cualquier orden.

Los cuatro principales áreas de proceso de Mejora

El punto a destacar aquí es que, independientemente de la clase de la tarea - ya sea manual o computarizado - es importante que cada tarea - y por lo tanto el proceso como un todo - ha sido diseñado y revisado periódicamente, mejorado o sustituido por otra tarea, con miras a la mejora continua en cuatro áreas principales:

1. Eficacia
2. Eficiencia
3. De control interno
4. El cumplimiento de diversas leyes y políticas

Estas áreas se explica por destacar las deficiencias típicas de cada uno de ellos, como en:

Eficacia

El general de la eficacia de un proceso es el grado en que los resultados esperados del proceso se están obteniendo en todo, y por lo tanto, una primera medida de la adecuación básica del proceso y su capacidad para cumplir con las expectativas lógicas y razonables de los usos de proceso y los operadores.
Por ejemplo, considere el proceso de adquisición de materiales. Una de sus tareas más importantes es el sub-proceso para el proveedor de seguimiento para asegurar la entrega oportuna de los materiales. Dicha tarea es considerablemente menos eficaz si no proporcionar información precisa y oportuna los informes de situación de compra para uso del personal del departamento de compra responsable de su seguimiento.

Eficiencia

Suponiendo que se ha observado que el tiempo medio necesario para preparar y enviar una orden de compra después de recibir una intención bien preparado desde el usuario final es inaceptablemente alto, lo que retrasó las entregas al cliente y reclamaciones de los clientes consecuentes.
El proceso de "convertir" a la intención del usuario final a una orden de compra es efectivo debido a una orden de compra se está de alguna manera genera, pero su eficiencia es muy baja ya que tiene una cantidad excesiva de tiempo y costes mucho más en términos del costo para la compañía de los sueldos de los funcionarios involucrados.

De Control Interno

En un escenario donde las cantidades de las principales materias primas son regularmente ordenado y se consume, las tasas son fijas con una selección, proveedores confiables, aprobado por un período prolongado - normalmente un año. Por otra parte, digamos que el contrato tipo no contiene una cláusula de ajuste de precios. Esto protege a la organización de la escalada de precios no previstos durante el período. El contrato de datos de la tasa se almacenan en la base de datos del sistema ERP. Siempre que los materiales deben ser ordenados (con o sin un programa de entrega), órdenes de compra se generan mencionar la tasa fue aprobado en el contrato tipo de cambio. Existe un control interno para mantener la tasa de compra constante a lo largo del año.
Supongamos, sin embargo, se encontró que la tasa en una orden de compra en base a un contrato de tarifa actual se cambia a un valor diferente, y la orden de compra enviada a los proveedores. Este es un grave error en el control interno, ya que un cambio a una tasa más alta expone a la empresa a una mayor responsabilidad financiera. Por otra parte, la posibilidad de editar la tasa de tal orden de compra anula por completo los controles internos siempre por tener un contrato de tasa en el primer lugar y como una cláusula de no-escalada en ella. No sería una violación adicional de control interno si se descubriera que una enmienda PO es realmente autorizado antes de enviar la orden de compra al proveedor.

El cumplimiento de diversas leyes y políticas

Hay ciertas situaciones en que los pagos efectuados a consultores o contratistas de servicios debe ser legalmente hecha después de deducir los impuestos en la fuente (TDS), y dichos montos TDS deben ser depositados en cuentas de tesorería del gobierno con los bancos en o antes de una fecha determinada en el mes siguiente al mes en el que se hacen los pagos.
En estos casos, si un proceso de negocio no prevé la deducción de TDS y / o no garantice el depósito en las cuentas del gobierno en la fecha indicada, entonces esta es una cuestión de cumplimiento legal que hace que los ejecutivos involucrados responsable a la sociedad civil / criminal acción legal.

Políticas, procesos y procedimientos

Las áreas de mejora anteriormente mencionadas son igualmente aplicables a las políticas, procesos y procedimientos detallados (sub-processes/tasks). Hay un efecto en cascada de las mejoras realizadas en un nivel superior en las realizadas en un nivel inferior.
Por ejemplo, si una recomendación para sustituir a una política determinada con uno mejor se hace con la debida justificación y aceptada en principio por los dueños de procesos de negocio, entonces los cambios correspondientes en los consiguientes procesos y procedimientos se siguen, naturalmente, con el fin de permitir la aplicación de las políticas

Manual / Administrativo vs PC basados ​​en el sistema de controles internos

Los controles internos se pueden construir en las etapas del proceso manual / administrativos y / o procedimientos del sistema informático.
Es recomendable crear en el sistema como muchos controles como sea posible, ya que estos controles, es automática, siempre será ejercida, ya que están integrados en el diseño del software del sistema de negocios. Por ejemplo, un mensaje de error impedir la entrada de una cantidad de material recibido primas superiores a la cantidad de la orden de compra por mayor que el porcentaje de tolerancia permitidos siempre se mostrará y se evitará que el usuario del sistema de la entrada de tal cantidad.
Sin embargo, por diversas razones, tales como la practicidad, la necesidad de ser "flexible" (sea lo que puede significar), la falta de conocimiento del negocio de dominio y la experiencia, las dificultades en el diseño / escritura de software, el costo de desarrollo de software / modificación, la incapacidad de un sistema informatizado sistema para proporcionar controles, etc, todos los controles internos de otro modo se consideren necesarias a menudo no están incorporados en los sistemas de negocios y software.
En tal escenario, los controles manuales, el proceso administrativo fuera del sistema informático debe estar claramente documentado, forzada y ejercicio con regularidad. Por ejemplo, al introducir los datos para crear un nuevo registro en la tabla de una base de datos del sistema material elemento maestro, el único control interno que el sistema puede proporcionar en el campo de la descripción del artículo no es para permitir que el usuario deje en blanco la descripción - en otras palabras, configurar la descripción del artículo, como un campo obligatorio. El sistema, obviamente, no puede avisar al usuario que la descripción está mal escrito, inadecuado, sin sentido, etc
En ausencia de un sistema basado en el control interno, el proceso de creación de objetos debe incluir un adecuado control administrativo a través de la verificación detallada, por un funcionario responsable, de todos los campos de entrada para el nuevo elemento, mediante la comparación de una impresión tomada de la sistema con la hoja de entrada de datos punto, y asegurar que las correcciones en la descripción del artículo (y otros campos similares, donde no hay sistema de control es posible) se llevó a cabo con prontitud.
Por último, pero no menos importante, la introducción del manual de efectivos, los controles administrativos por lo general requiere una comprobación periódica primordial por una autoridad superior para asegurarse de que tales controles se ejercen en el primer lugar.

Informes de la información como una base esencial para los procesos de negocio Ejecución

Los procesos de negocio debe incluir hasta a la fecha e informes precisos de información para garantizar una acción eficaz. Un ejemplo de esto es la disponibilidad de informes de estado de la orden de compra para la entrega del proveedor de seguimiento como se describe en la sección sobre la eficacia de arriba. Hay numerosos ejemplos de esto en todos los procesos de negocio posible.
Otro ejemplo de la producción es el proceso de análisis de los rechazos de la línea que ocurren en el taller. Este proceso debe incluir un análisis sistemático periódico de los rechazos por la razón, y presentar los resultados en un informe la información adecuada que señala las principales razones, y las tendencias de estas razones, la gestión para tomar acciones correctivas para el control de rechazos y mantenerlos dentro de límites aceptables. Este proceso de análisis y resumen de los eventos de rechazo de línea es claramente superior a un proceso que sólo indaga en cada individuo como el rechazo se produce.
Los propietarios de procesos de negocio y operativos deben darse cuenta de que la mejora de procesos a menudo se produce con la introducción de la transacción procede, los informes de actividades, destacan, excepción o MIS, siempre que sean utilizados conscientemente para el día a día o periódica de toma de decisiones. Con este entendimiento de esperar que venga la buena voluntad de invertir tiempo y otros recursos en la mejora de procesos de negocio mediante la introducción de sistemas de información útil y relevante.

Las teorías y los conceptos de apoyo

Frederick Winslow Taylor desarrolló el concepto de la gestión científica . El concepto contiene aspectos sobre la división del trabajo es relevante para la teoría y práctica en torno a los procesos de negocio. Los aspectos relacionados con procesos de negocio del concepto de la gestión científica de Taylor se discuten en el artículo sobre la Reingeniería de Procesos .

El alcance del control

El alcance del control es el número de subordinados que un supervisor maneja dentro de una estructura organización . La introducción de un concepto de proceso de negocio tiene un impacto considerable en los elementos estructurales de la organización y por lo tanto también en el ámbito de control.
Las grandes organizaciones que no están organizados como los mercados deben ser organizados en unidades más pequeñas - departamentos - que puede ser definido de acuerdo con principios diferentes.

Conceptos de gestión de información

Gestión de la Información y las estrategias de diseño de la organización están relacionados con él, son una piedra angular teórica del concepto de procesos de negocio.
 
 

4. Data Warehouse

Un almacén de datos (DW) es una base de datos utilizada para la presentación de informes y análisis. Los datos almacenados en el depósito es cargado desde los sistemas operacionales. Los datos pueden pasar a través de un almacén de datos operativos de las operaciones adicionales antes de que se utiliza en el DW para la presentación de informes.
Un almacén de datos mantiene sus funciones en tres capas:. Staging puesta en escena, la integración y el acceso se utiliza para almacenar los datos en bruto para su uso por los desarrolladores. La capa de integración se utiliza para integrar los datos y tener un nivel de abstracción de los usuarios. La capa de acceso es para obtener datos de los usuarios.
Los almacenes de datos se puede subdividir en los data marts . Data marts almacenar subconjuntos de datos de un almacén.
Esta definición del almacén de datos se centra en el almacenamiento de datos. La principal fuente de los datos se limpia, se transforma, catalogados y disponibles para su uso por los administradores y otros profesionales de la minería de datos , procesamiento analítico en línea , investigación de mercados y apoyo a las decisiones (Marakas y O'Brien 2009). Sin embargo, los medios para recuperar y analizar los datos, para extraer, transformar y cargar datos, y para manejar el diccionario de datos también se consideran componentes esenciales de un sistema de almacenamiento de datos. Muchas referencias a almacenamiento de datos utilizan este contexto más amplio. Por lo tanto, una definición más amplia para el almacenamiento de datos incluye herramientas de inteligencia empresarial , herramientas para extraer, transformar y cargar datos en el repositorio, y las herramientas para gestionar y recuperar los metadatos .

Beneficios de un almacén de datos

Un almacén de datos mantiene una copia de la información de los sistemas de código de transacción. Esta complejidad de la arquitectura ofrece la oportunidad de:

• Mantener el historial de datos, incluso si los sistemas de transacción de origen no.
• Integrar datos de múltiples sistemas de origen, lo que permite una vista central de toda la empresa. Este beneficio es siempre valiosa, pero especialmente cuando la organización ha crecido por la fusión.
• Mejorar la calidad de los datos , al proporcionar los códigos y descripciones consistentes, marcar o incluso la fijación de los datos erróneos.
• Presentar la información de la organización constantemente.
• Proporcionar un único modelo de datos común para todos los datos de interés independientemente de la fuente de los datos.
• Reestructurar los datos de manera que tenga sentido para los usuarios de negocios.
• Reestructurar los datos de manera que proporciona un rendimiento excelente de consulta, incluso para las consultas analíticas complejas, sin afectar el sistema operativo .
• Agregar valor a las aplicaciones de negocio operativa, en particular la gestión de relaciones con clientes (CRM).

Enfoque normalizado en comparación con dimensiones para el almacenamiento de datos

Hay dos enfoques principales para almacenar datos en un almacén de datos - el enfoque multidimensional y el enfoque normalizado. El enfoque multidimensional, cuyos seguidores son conocidos como "Kimballites", creen en Ralph Kimball enfoque 's en el que se afirma que el almacén de datos debe ser modelado utilizando un modelo dimensional / esquema en estrella . El enfoque normalizado, también llamado el modelo de 3FN, cuyos seguidores son conocidos como "Inmonites", creen en el enfoque de Bill Inmon en el que se afirma que el almacén de datos debe ser modelado utilizando un modelo ER / modelo normalizado.
En un enfoque multidimensional , los datos de transacciones se dividen en cualquiera de los "hechos", que generalmente son los datos numéricos de transacción, o " dimensiones ", que son la información de referencia que da contexto a los hechos. Por ejemplo, una transacción de venta puede ser dividido en hechos tales como el número de productos solicitados y el precio pagado por los productos, y en dimensiones tales como la fecha del pedido, nombre del cliente, número de producto, a fin de buques y la factura a lugares , y el vendedor responsable de la recepción del pedido.
Una ventaja clave de un enfoque multidimensional es que el almacén de datos es más fácil para el usuario a entender y utilizar. Además, la recuperación de datos del almacén de datos tiende a operar muy rápidamente. Estructuras tridimensionales son fáciles de entender para los usuarios empresariales, ya que la estructura se divide en las mediciones / hechos y el contexto / dimensiones. Los hechos están relacionados con los procesos de negocio de la organización y el sistema operativo, mientras que las dimensiones que les rodea contienen contexto de la medición (Kimball, Ralph 2008).
Las principales desventajas del enfoque de dimensiones son las siguientes:

1. Con el fin de mantener la integridad de los hechos y las dimensiones, la carga del almacén de datos con datos de diferentes sistemas operativos es complicado, y
2. Es difícil modificar la estructura del almacén de datos si la organización de la adopción del enfoque dimensional cambia la forma en que opera.

En el enfoque normalizado, los datos del almacén de datos se almacenan siguientes, hasta cierto punto, base de datos de normalización de las reglas. Las tablas se agrupan por áreas temáticas que reflejan las categorías de datos en general (por ejemplo, los datos sobre clientes, productos, finanzas, etc.) La estructura normalizada divide los datos en las entidades, lo que crea varias tablas en una base de datos relacional. Cuando se aplica en las grandes empresas es el resultado de docenas de tablas que están vinculadas entre sí por una red de uniones. Además, cada una de las entidades creadas se convierten en tablas físicas separadas, cuando la base de datos se lleva a cabo (Kimball, Ralph 2008). La principal ventaja de este enfoque es que es sencillo de añadir información en la base de datos. Una desventaja de este enfoque es que, debido a la cantidad de tablas relacionadas, puede ser difícil para los usuarios a:

1. unir datos de diferentes fuentes en información significativa y
2. acceder a la información sin un conocimiento preciso de las fuentes de datos y de la estructura de datos del almacén de datos.

Cabe señalar que ambos normalizaron - modelos y dimensiones puede ser representada en los diagramas de entidad-relación ya que ambos contienen articulado tablas relacionales. La diferencia entre los dos modelos es el grado de normalización.
Estos enfoques no son mutuamente excluyentes, y hay otros enfoques. Enfoques dimensiones puede implicar la normalización de los datos en un grado (Kimball, Ralph 2008).
En impulsada por la información de negocios (Wiley 2010), Robert Hillard propone un acercamiento a la comparación de los dos enfoques sobre la base de las necesidades de información del problema de negocio. La técnica muestra que los modelos normalizados tienen mucha más información que sus equivalentes en dimensiones (incluso cuando los campos se utilizan las mismas en ambos modelos), pero esta información adicional se produce en el costo de la facilidad de uso. La técnica mide la cantidad de información en términos de entropía de la información y usabilidad en términos de la medida de transformación de los mundos pequeños de datos.

De arriba hacia abajo versus de abajo hacia arriba metodologías de diseño

Diseño ascendente

Ralph Kimball , un autor muy conocido en el almacenamiento de datos, es un gran defensor de un enfoque de diseño de almacenes de datos que describe como de abajo hacia arriba.
En el enfoque de abajo arriba data marts son creados para proporcionar capacidades de reporting y análisis para determinados procesos de negocio . Aunque es importante señalar que en la metodología de Kimball, el proceso de abajo hacia arriba es el resultado de un negocio inicial orientado de arriba a abajo el análisis de los procesos de negocio relevantes a modelar.
Data marts contienen, principalmente, las dimensiones y los hechos. Los hechos pueden contener datos atómicos y, si es necesario, que se resumen los datos. El único mercado de datos a menudo modelos de un área específica como "Ventas" o "producción". Estos data marts pueden llegar a ser integradas para crear un almacén de datos completo. La integración de los mercados de datos se gestiona mediante la aplicación de lo Kimball llama "un almacén de datos la arquitectura de bus". El almacén de datos la arquitectura de bus es principalmente una aplicación del "bus", una colección de dimensiones compatibles y hechos conformados , que son dimensiones que se comparten (de una manera específica) entre los hechos en dos o más mercados de datos.
La integración de los mercados de datos en el almacén de datos se centra en las dimensiones compatibles (que residen en el "bus") que definen la posible integración de los "puntos" entre los mercados de datos. La integración real de dos o más mercados de datos se realiza entonces por un proceso conocido como "taladro a través de". Una perforación a través de obras de agrupación (resumen) los datos a lo largo de las llaves de las dimensiones (compartido) conformada de cada hecho de participar en el "taladro a través de", seguido de una combinación en las claves de estos agrupados (resumen) los hechos.
Para mantener el manejo estricto de la arquitectura de bus de almacenamiento de datos es fundamental para mantener la integridad del almacén de datos. La tarea de gestión más importante es hacer que las dimensiones de los mercados de datos son consistentes. En palabras de Kimball, esto significa que las dimensiones de "conformarse".
Algunos lo consideran una ventaja del método de Kimball, que el almacén de datos termina siendo "segmentado" en una serie de lógica autónoma (hasta e incluyendo el autobús) y data marts coherente, en lugar de un modelo centralizado grandes ya menudo complejas. El valor del negocio puede ser devuelto tan pronto como los primeros puestos de datos se pueden crear, y el método se da bien en un estudio exploratorio y enfoque iterativo para la construcción de almacenes de datos. Por ejemplo, el esfuerzo de almacenamiento de datos puede comenzar en la "venta" del departamento, mediante la construcción de un centro comercial de los datos de ventas. Una vez finalizado el mercado de datos de ventas, la empresa podría decidir ampliar las actividades de almacenamiento en el "Departamento de Producción", por ejemplo, que resulta en un mercado de producción de datos. El requisito para el mercado de venta de datos y el mercado de producción de datos para ser integrable, es que comparten el mismo "Bus", que será, que el equipo de almacenamiento de datos ha hecho el esfuerzo de identificar e implementar las dimensiones compatibles en el autobús, y que los centros comerciales de datos individuales de los vínculos que la información del bus. Tenga en cuenta que esto no requiere un 100% la conciencia desde el inicio de los esfuerzos de almacenamiento de datos, un plan maestro se requiere por adelantado. La bolsa de los datos de ventas es bueno, ya que es (suponiendo que el autobús está completo) y el mercado de producción de datos se puede construir prácticamente independiente de los datos de ventas de mercado (pero no independiente de la de autobuses).
Si la integración a través del bus se logra, el almacén de datos, a través de sus dos mercados de datos, no sólo será capaz de entregar la información específica que los mercados de datos individuales están diseñados para hacer, en este ejemplo sea "Ventas" o información "de producción" , pero puede ofrecer un grupo de ventas, la producción de información, que, a menudo, tiene un valor de negocio críticos. Una integración (posiblemente) logró de manera flexible e iterativo de la moda.

Diseño top-down

Bill Inmon , uno de los primeros autores en el tema del almacenamiento de datos, ha definido un almacén de datos como un repositorio centralizado para toda la empresa. Inmon es uno de los principales proponentes del enfoque de arriba hacia abajo a los datos de diseño del almacén, en la que el almacén de datos se ha diseñado utilizando una empresa normalizada modelo de datos . "Atomic" de datos , es decir, los datos con el menor nivel de detalle, se almacenan en el data warehouse. Data marts dimensionales que contienen los datos necesarios para los procesos de negocio o departamentos específicos se crean a partir del almacén de datos. En la visión Inmon el almacén de datos está en el centro de la "Fábrica de Información Corporativa" (CIF), que proporciona un marco lógico para la prestación de inteligencia empresarial (BI) y las capacidades de gestión empresarial.
Inmon afirma que el almacén de datos es la siguiente:

Un tema en particular

Los datos en el data warehouse está organizado para que todos los elementos de los datos relativos a los mismos en el mundo real acontecimiento u objeto están unidos entre sí.

No volátil

Datos en el almacén de datos no se sobre-escrito o borrado - una vez cometido, los datos son estáticos y de sólo lectura, y retenidos para futuros informes.

Integrado

El almacén de datos contiene datos de la mayoría o la totalidad de los sistemas operativos de una organización y estos datos se hizo constante.

Variaciones en el tiempo

Para que un sistema operativo, los datos almacenados contiene el valor actual.

La metodología de diseño de arriba hacia abajo genera vistas tridimensionales muy consistente de los datos en los data marts desde todos los puestos de datos se cargan desde el repositorio centralizado. Diseño top-down también ha demostrado ser robusto frente a los cambios del negocio. La generación de nuevos puestos de datos dimensional frente a los datos almacenados en el almacén de datos es una tarea relativamente simple. El principal inconveniente de la metodología de arriba hacia abajo es que representa un proyecto muy grande, con un alcance muy amplio. El costo inicial para implementar un almacén de datos utilizando la metodología de arriba hacia abajo es importante, y la duración de tiempo desde el inicio del proyecto hasta el punto de que los usuarios finales la experiencia inicial de los beneficios pueden ser considerables. Además, la metodología de arriba hacia abajo puede ser inflexible y no responde a las cambiantes necesidades del servicio durante las fases de ejecución.

Diseño híbrido

Almacenamiento de datos (DW) soluciones a menudo se asemejan la arquitectura hub and spoke . Los sistemas de legado la alimentación de los DW / solución de BI incluyen a menudo la gestión de relaciones con clientes (CRM) y planificación de recursos empresariales soluciones (ERP), lo que genera grandes cantidades de datos. Para consolidar estos modelos de datos diferentes, y facilitar la transformación de extraer la carga (ETL), las soluciones de DW a menudo hacen uso de un almacén de datos operacionales (ODS). La información de la SAO a continuación se analiza en el DW real. Para reducir la redundancia de datos, sistemas de gran tamaño a menudo se almacenan los datos en una forma normalizada. Mercados de datos para los informes específicos, entonces se puede construir en la parte superior de la solución de DW.
Es importante señalar que la base de datos DW en una solución híbrida que se mantiene en la tercera forma normal para eliminar la redundancia de datos. Una base de datos relacional normal, sin embargo, no es eficiente para los informes de inteligencia de negocios donde el modelado dimensional es frecuente. Data marts pequeñas pueden comprar datos del almacén de consolidación y el uso de los datos filtrados, específicas para las tablas de hechos y dimensiones requeridas. El DW proporciona efectivamente una sola fuente de información de la que data marts se puede leer, crear una solución altamente flexible desde el punto de vista de BI. La arquitectura híbrida permite un DW para ser reemplazada por una gestión de datos maestros solución en la que la información operativa, no estática podría residir.
Los componentes de modelado de datos de Vault seguir la arquitectura hub and spoke  . Este estilo de modelado es un diseño híbrido, que consiste en la mejor de las prácticas de cría de tanto en forma normal y tercera esquema en estrella. El modelo de Data Vault no es un verdadero 3era forma normal, y rompe algunas de las reglas que dicta 3FN seguir. Sin embargo, es una arquitectura de arriba a abajo con un diseño de abajo hacia arriba. El modelo de Data Vault está orientado a ser estrictamente un almacén de datos. No está orientado a ser accesible para el usuario final, que cuando se construyó, todavía requiere el uso de un data mart o una estrella de la zona del esquema de liberación basada por motivos de negocios.

Los almacenes de datos en comparación con los sistemas operativos

Los sistemas operativos están optimizados para la preservación de la integridad de datos y la velocidad de grabación de las transacciones comerciales a través del uso de la normalización de bases de datos y un modelo entidad-relación . Los diseñadores del sistema operativo en general siguen la Codd reglas de normalización de bases de datos con el fin de garantizar la integridad de los datos. Codd definió cinco reglas cada vez más estrictos de la normalización. Totalmente normalizado diseños de bases de datos (es decir, personas que cumplen las cinco reglas de Codd) a menudo resultan en la información de una transacción comercial que se almacenan en decenas a cientos de mesas. Bases de datos relacionales son eficientes en la gestión de las relaciones entre estas tablas. Las bases de datos tienen muy rápida inserción / actualización de rendimiento, ya que sólo una pequeña cantidad de datos en las tablas se ve afectada cada vez que se procesa la transacción. Finalmente, con el fin de mejorar el rendimiento, los datos más antiguos suelen ser purgado periódicamente de los sistemas operacionales.
Los almacenes de datos están optimizadas para la velocidad de análisis de datos. Con frecuencia los datos de los almacenes de datos son desnormalizaremos a través de un modelo basado en la dimensión . Además, para acelerar la recuperación de datos, almacenamiento de datos a menudo se almacenan en varias ocasiones su forma más granular y en forma resumida llamadas agregados. Los datos de almacenamiento de datos se obtienen de los sistemas operacionales y se mantiene en el almacén de datos, incluso después de que los datos han sido eliminados de los sistemas operativos.

Evolución en el uso de la organización

Estos términos se refieren al nivel de sofisticación de un almacén de datos:

Almacén de datos fuera de línea operativa

Los almacenes de datos en esta etapa de la evolución se actualizan en un ciclo de tiempo regulares (generalmente diaria, semanal o mensual) de los sistemas operativos y los datos se almacenan en un sistema integrado de información orientado a los datos

Almacenamiento de datos en línea

Los almacenes de datos en esta etapa se actualizan los datos en los sistemas operativos de forma regular y los datos de almacenamiento de datos se almacenan en una estructura de datos diseñada para facilitar la presentación de informes.

El tiempo de almacenamiento de datos

Almacenamiento de datos en línea integrada de representar los datos en tiempo real los almacenes de datos etapa en el almacén se actualiza para cada transacción realizada en los datos de origen

Integrado de almacenamiento de datos

Estos almacenes de datos de reunir datos de diferentes áreas de negocio, por lo que los usuarios pueden consultar la información que necesitan a través de otros sistemas

Aplicaciones de ejemplo

Algunas de las aplicaciones de almacenamiento de datos se puede utilizar para son:

• Apoyo a las decisiones
• Análisis de tendencias
• La previsión financiera
• Los usuarios de tarjetas de crédito, etc
• Análisis de fraudes de seguros
• Logística y gestión de inventario
• La agricultura 

3. Modelo Multidimensional

Introduccion
La tecnología Datawarehousing debido a su orientación analítica, impone un procesamiento y
pensamiento distinto, la cual se sustenta por un modelamiento de Bases de Datos propio, conocido
como Modelamiento Multidimensional, el cual busca ofrecer al usuario su visión respecto de la operación del negocio.Modelamiento Dimensional es una técnica para modelar bases de datos simples y entendibles al usuariofinal. La idea fundamental es que el usuario visualice fácilmente la relación que existe entre las distintas componentes del modelo.

Consideremos un punto en el espacio. El espacio se define a través de sus ejes coordenados (por
ejemplo X, Y, Z). Un punto cualquiera de este espacio quedará determinado por la intersección de tres
valores particulares de sus ejes.

Si se le asignan valores particulares a estos ejes. Digamos que el eje X representa Productos, el eje Y
representa el Mercado y, el eje Z corresponde al Tiempo. Se podría tener por ejemplo, la siguiente
combinación: producto = madera, mercado = Concepción, tiempo = diciembre-1998. La intersección de
estos valores nos definirá un solo punto en nuestro espacio. Si el punto que buscamos, lo definimos
como la cantidad de madera vendida, entonces se tendrá un valor específico y único para tal
combinación.

En el modelo multidimensional cada eje corresponde a una dimensión particular . Entonces la
dimensionalidad de nuestra base estará dada por la cantidad de ejes (o dimensiones) que le asociemos.
Cuando una base puede ser visualizada como un cubo de tres o más dimensiones, es más fácil para el
usuario organizar la información e imaginarse en ella cortando y rebanando el cubo a través de cada
una de sus dimensiones, para buscar la información deseada.

1.1 Modelos de Datos
Un factor clave presente durante todo el dise ño de un DW, fue expresado por Codd en 1983: “Ustedes
pueden pensar que el significado de los datos es simple...pero no es así”.[Oviedo98]

Para construir un DW se debe primero tener claro que existe una diferencia entre la estructura de la
información y la semántica de la información, y que esta última es mucho más difícil de abarcar y que también es precisamente con ella con la que se trabaja en la construcción de un DW.
Aquí se encuentra la principal diferencia entre los sistemas operacionales y el DW: Cada uno de ellos es sostenido por un modelo de datos diferente. Los sistemas operacionales se sustentan en el Modelo
Entidad Relación (MER) y DDW trabaja con el Modelo Multidimensional.

1.1.1 Características del MER

• Maneja la redundancia fuera de los datos. Por lo tanto realizar un cambio en la base significa tocarla en un solo lugar.
• Divide los datos en entidades, las que son representadas como tablas en una base de datos.
• Los MER crecen fácilmente, haciéndose más y más complejos.Se puede apreciar la existencia de muchos caminos para ir de una tabla a otra. 
• Sería natural pensar que al tener diversos caminos para llegar desde una tabla a otra, cualquiera de ellos entregaría el mismo resultado, pero lamentablemente esto no siempre sucede así. 
• El diagrama se visualiza simétrico, donde todas las tablas se parecen, sin distinguir a priori la
  importancia de unas respecto a otras. 
• No es fácil de entender tanto para usuarios como para los diseñadores.

1.1.2 Características del Modelo Multidimensional

En general, la estructura básica de un DW para el Modelo Multidimensional está definida por dos
elementos: esquemas y tablas.
Tablas DW: como cualquier base de datos relacional, un DW se compone de tablas. Hay dos tipos
básicos de tablas en el Modelo Multidimensional:
Tablas Fact : contienen los valores de las medidas de negocios, por ejemplo: ventas promedio en
Modelamiento Multidimensional dólares, n úmero de unidades vendidas, etc.
Tablas Lock_up: contienen el detalle de los valores que se encuentran asociados a la tabla Fact.
Esquemas DW: la colección de tablas en el DW se conoce como Esquema. Los esquemas caen dentro
de dos categorías básicas: esquemas estrellas y esquemas snowflake.

1.2 Conceptos asociados al DDW

1.2.1 Esquema Estrella.
En general, el modelo multidimensional también se conoce con el nombre de esquema estrella, pues su estructura base es similar: una tabla central y un conjunto de tablas que la atienden radialmente. a
El esquema estrella deriva su nombre del hecho que su diagrama forma una estrella, con puntos
radiales desde el centro. El centro de la estrella consiste de una o más tablas fact, y las puntas de la
estrella son las tablas lock_up.
Este modelo entonces, resulta ser asimétrico, pues hay una tabla dominante en el centro con varias
conexiones a las otras tablas. Las tablas Lock-up tienen s ólo la conexión a la tabla fact y ninguna más.





FIGURA: EJEMPLO DE UN ESQUEMA ESTRELLA PARA UNA BASE DE DATOS CON DIMENSIONES DE TIEMPO, PRODUCTO, MERCADO Y CLIENTE.

1.2.2 Esquema Snowflake.

La diferencia del esquema snowflake comparado con el esquema estrella, está en la estructura de las
tablas lock_up: las tablas lock_up en el esquema snowflake están normalizadas. Cada tabla lock_up
contiene sólo el nivel que es clave primaria en la tabla y la foreign key de su parentesco del nivel más
cercano del diagrama.



FIGURA 2: EJEMPLO DE UN ESQUEMA SNOWFLAKE PARA EL EJEMPLO ANTERIOR.

1.2.3 Tabla Fact o de Hechos.

Es la tabla central en un esquema dimensional. Es en ella donde se almacenan las mediciones
numéricas del negocio. Estas medidas se hacen sobre el grano, o unidad básica de la tabla.
El grano o la granularidad de la tabla queda determinada por el nivel de detalle que se almacenará en la tabla. Por ejemplo, para el caso de producto, mercado y tiempo antes visto, el grano puede ser la
cantidad de madera vendida ‘mensualmente’. El grano revierte las unidades atómicas en el esquema
dimensional.
Cada medida es tomada de la intersección de las dimensiones que la definen. Idealmente está
compuesta por valores numéricos, continuamente evaluados y aditivos. La razón de estas
Modelamiento Multidimensional características es que así se facilita que los miles de registros que involucran una consulta sean comprimidos en unas pocas l íneas en un set de respuesta.
La clave de la tabla fact recibe el nombre de clave compuesta o concatenada debido a que se forma de la composición (o concatenaci ón) de las llaves primarias de las tablas dimensionales a las que está unida.
Así entonces, se distinguen dos tipos de columnas en una tabla fact: columnas fact y columnas key.
Donde la columna fact es la que almacena alguna medida de negocio y una columna key forma parte
de la clave compuesta de la tabla.

1.2.4 Tablas Lock-up o Dimensionales

Estas tablas son las que se conectan a la tabla fact, son las que alimentan a la tabla fact. Una tabla
lock_up almacena un conjunto de valores que están relacionados a una dimensión particular. Tablas
lock_up no contienen hechos, en su lugar los valores en las tablas lock_up son los elementos que
determinan la estructura de las dimensiones. Así entonces, en ellas existe el detalle de los valores de la dimensión respectiva.
Una tabla lock_up está compuesta de una primary key que identifica unívocamente una fila en la tabla junto con un conjunto de atributos, y dependiendo del diseño del modelo multidimensional puede existir una foreign key que determina su relación con otra tabla lock_up.
Para decidir si un campo de datos es un atributo o un hecho se analiza la variación de la medida a
través del tiempo. Si varía continuamente implicaría tomarlo como un hecho, caso contrario será un
atributo.
Los atributos dimensionales son un rol determinante en un DDW. Ellos son la fuente de todas las
necesidades que debieran cubrirse. Esto significa que la base de datos será tan buena como lo sean los atributos dimensionales, mientras más descriptivos, manejables y de buena calidad, mejor será el
DDW.

1.3 Pasos básicos del Modelamiento Multidimensional

1. Decidir cuáles serán los procesos de negocios a modelar, basándose en el conocimiento de éstos y
de los datos disponibles. Ejemplo: Gastos realizados por cada mercado para cada ítem a nivel
mensual. Productos vendidos por cada mercado según el precio en cada mes.
2. Decidir el Grano de la tabla Fact de cada proceso de negocio.
Ejemplo : Producto x mercado x tiempo. En este punto se debe tener especial cuidado con la
magnitud de la base de datos, con la información que se tiene y con las preguntas que se quiere
responder. El grano decidirá las dimensiones del DDW. Cada dimensión debe tener el grano m ás
pequeño que se pueda puesto que las preguntas que se realicen necesitan cortar la base en
caminos precisos (aunque las preguntas no lo pidan expl ícitamente).
3. Decidir las dimensiones a través del grano. Las dimensiones presentes en la mayoría de los DDW
son: tiempo, mercado, producto, cliente. Un grano bien elegido determina la dimensionalidad
primaria de la tabla fact. Es posible usualmente agregar dimensiones adicionales al grano básico
de la tabla fact, donde estas dimensiones adicionales toman un solo valor para cada combinación
de las dimensiones primarias. Si se reconoce que una dimensión adicional deseada viola el grano
por causar registros adicionales a los generados, entonces el grano debe ser revisado para
acomodar esta dimensión adicional.
4. Elegir las mediciones del negocio para la tabla fact. Se deben establecer los ítemes que quedarán
determinados por la clave compuesta de la tabla fact.

1.4.1 La Dimensión Tiempo

Virtualmente se garantiza que cada DDW tendrá una tabla dimensional de tiempo, debido a la
perspectiva de almacenamiento histórica de la información. Usualmente es la primera dimensión en
definirse, con el objeto de establecer un orden, ya que la inserción de datos en la base de datos
multidimensional se hace por intervalos de tiempo, lo cual asegura un orden implícito.

1.4.2 Dimensiones que var ían lentamente en el tiempo
Son aquellas dimensiones que se mantienen “casi” constantes en el tiempo y que pueden preservar la
estructura dimensional independiente del tiempo, con s ólo agregados menores relativos para capturar la naturaleza cambiante del tiempo.
Cuando se encuentra una de estas dimensiones se está haciendo una de las siguientes fundamentales
tres elecciones. Cada elección resulta en un diferente grado de seguimiento sobre el tiempo:
Tipo 1: Sobreescribir el viejo valor en el registro dimensional y por lo tanto perder la capacidad de
seguir la vieja historia.
Tipo 2: Crear un registro dimensional adicional (con una nueva llave) que permita registrar el cambio
presentado por el valor del atributo. De esta forma permanecerían en la base tanto el antiguo como el
nuevo valor del registro con lo cual es posible segmentar la historia de la ocurrencia.
Tipo 3: Crear un campo “actual” nuevo en el registro dimensional original el cual almacene el valor del nuevo atributo, manteniendo el atributo original también. Cada vez que haya un nuevo cambio en el atributo, se modifica el campo “actual” solamente. No se mantiene un registro histórico de los cambios intermedios.
1.4.3 Niveles
Un nivel representa un nivel particular de agregación dentro de una dimensión; cada nivel sobre el nivel
base representa la sumarización total de los datos desde el nivel inferior. Para un mejor entendimiento,
veamos el siguiente ejemplo: consideremos una dimensión Tiempo con tres niveles: Mes, Semestre,
Año. El nivel Mes representa el nivel base, el nivel Semestre representa la sumarización de los totales por Mes y el nivel A ño representa la sumarización de los totales para los Semestres.
Agregar niveles de sumarización otorga flexibilidad adicional a usuarios finales de aplicaciones EIS/ DSS para analizar los datos.

1.4.4 Sobre Jerarquías
A nivel de dimensiones es posible definir jerarquías, las cuales son grupos de atributos que siguen un
orden preestablecido.
Una jerarquía implica una organización de niveles dentro de una dimensión, con cada nivel
representando el total agregado de los datos del nivel inferior. Las jerarquías definen cómo los datos
son sumarizados desde los niveles más bajos hacia los más altos. Una dimensión típica soporta una o
más jerarquías naturales. Una jerarquía puede pero no exige contener todos los valores existentes en la dimensión .
Se debe evitar caer en la tentación de convertir en tablas dimensionales separadas cada una de las
relaciones muchos-a-uno presentes en las jerarquías. Esta descomposición es irrelevante en el planeamiento del espacio ocupado en disco y s ólo dificulta el entendimiento de la estructura para el
usuario final, además de destruir el desempeño del browsing.

1. Inteligencia de Negocios

Business Intelligence (BI) se refiere principalmente al equipo basado en las técnicas utilizadas en la identificación, extracción , y el análisis de los datos de negocio, tales como los ingresos por ventas de productos y / o departamentos, o por los costos asociados y los ingresos.

Tecnologías de BI proporcionan vistas históricas, actuales y predicción de las operaciones comerciales. Funciones comunes de las tecnologías de inteligencia de negocios están reportando, procesamiento analítico en línea , análisis , minería de datos , proceso de minería , procesamiento de eventos complejos , gestión del rendimiento empresarial , benchmarking , minería de textos y análisis predictivo .

La inteligencia de negocios tiene como objetivo apoyar una mejor toma de decisiones empresariales. Así, un sistema de BI puede ser llamado un sistema de apoyo a las decisiones (DSS). A pesar de la inteligencia empresarial a largo plazo a veces se usa como sinónimo de inteligencia competitiva , ya que tanto la toma de decisiones de apoyo, utiliza las tecnologías de BI, los procesos y aplicaciones para analizar en su mayoría internos, datos estructurados y procesos de negocio, mientras que la inteligencia competitiva recoge, analiza y difunde información con un enfoque de actualidad sobre los competidores de la empresa. La inteligencia de negocios entenderse en sentido amplio puede incluir el subconjunto de la inteligencia competitiva.

Business Intelligence y data warehousing

A menudo, las aplicaciones de BI uso de los datos recogidos en un almacén de datos o data mart . Sin embargo, no todos los almacenes de datos se utilizan para inteligencia de negocios, ni todas las aplicaciones de inteligencia empresarial requiere un almacén de datos.
Con el fin de distinguir entre los conceptos de inteligencia de negocios y almacenes de datos, Forrester Research a menudo define la inteligencia de negocios en una de dos maneras:
Utilizando una definición amplia: "Business Intelligence es un conjunto de metodologías, procesos, arquitecturas y tecnologías que transforman datos en información significativa y útil que se usa para permitir más eficaz una visión estratégica, táctica y operativa y la toma de decisiones". Cuando se utiliza esta definición, la inteligencia de negocios también incluye tecnologías como la integración de datos, calidad de datos, almacenamiento de datos, gestión de datos maestros, textos y análisis de contenido, y muchos otros que a veces el mercado de masas en la gestión de la información del segmento. Por lo tanto, Forrester se refiere a la preparación de datos y el uso de datos como dos separados, pero estrechamente vinculados segmentos de la pila de inteligencia de negocios de arquitectura.
Forrester define el mercado de este último, más estrecha de inteligencia de negocios como "sólo se refiere a las capas superiores de la pila de BI arquitectónicos, tales como informes, análisis y cuadros de mando ".

 

 

 

 

 

Inteligencia de negocios y análisis de negocios

Thomas Davenport ha argumentado que la inteligencia de negocio se debe dividir en consultas , informes , OLAP , una "alerta" de la herramienta, y análisis de negocios . En esta definición, análisis de negocios es el subconjunto de BI basadas en las estadísticas, la predicción y optimización. 

Aplicaciones en una empresa

La inteligencia de negocios se pueden aplicar a los siguientes fines comerciales (MARCKM), con el fin de impulsar el valor de negocio:

1. Medición - programa que crea una jerarquía de indicadores de desempeño (véase también el modelo de métricas de referencia ) y de referencia que informa a los empresarios sobre los avances hacia los objetivos de negocio ( Business Process Management ).
2. Analytics - programa que establece los procesos cuantitativos de una empresa para llegar a decisiones óptimas para realizar el descubrimiento y conocimiento del negocio. Con frecuencia se refiere a: la minería de datos , minería de proceso , análisis estadístico , análisis predictivo , modelos de predicción , modelado de procesos de negocios , procesamiento de eventos complejos .
3. Informes / empresa que presenta - el programa que se basa la infraestructura de información estratégica para servir a la gestión estratégica de un negocio, no informes de operaciones. Con frecuencia implica la visualización de datos , sistema de información ejecutiva y OLAP .
4. Colaboración / plataforma de colaboración - programa que se las distintas áreas (tanto dentro como fuera de la empresa) para trabajar juntos a través de intercambio de datos y el intercambio de datos electrónicos .
5. La gestión del conocimiento - programa para hacer que los datos de la empresa impulsada a través de estrategias y prácticas para identificar, crear, representar, distribuir y permitir la adopción de ideas y experiencias que son de conocimiento de negocio real. La gestión del conocimiento lleva a la gestión del aprendizaje y de cumplimiento normativo / cumplimiento .

Además de lo anterior, la inteligencia de negocios también puede proporcionar un enfoque pro-activo, tales como la función de alarma para alertar de inmediato a los usuarios finales. Hay muchos tipos de alertas, por ejemplo, si algún valor de negocio supera el umbral del color de esa cantidad en el informe se vuelve rojo y el analista de negocios es alertado. A veces un mail será enviado al usuario también. Este extremo a otro proceso requiere la gobernabilidad de datos, que debe ser manejado por el experto.

Priorización de proyectos de Business Intelligence

A menudo es difícil establecer un modelo de negocios positivo para las iniciativas de inteligencia de negocios y, a menudo los proyectos tendrán que ser priorizados a través de iniciativas estratégicas. He aquí algunas sugerencias para aumentar los beneficios de un proyecto de BI.

• Según lo descrito por Kimball debe determinar los beneficios tangibles tales como el costo de eliminar la producción de informes anteriores.
• Forzar un acceso a los datos para toda la organización. De esta manera, incluso un pequeño beneficio, como por ejemplo unos minutos salvó, hará una diferencia en lo que se multiplica por el número de empleados en toda la organización.
• Según lo descrito por Ross, Weil y Roberson para Enterprise Architecture, considere dejar que el proyecto BI ser impulsada por otras iniciativas empresariales con casos de negocio excelente. Para apoyar este enfoque, la organización debe tener Enterprise Architects, que será capaz de detectar los proyectos adecuados de negocios.

Factores de éxito de la aplicación

Antes de implementar una solución de BI, vale la pena tomar en cuenta diversos factores antes de proceder. . Según Kimball et al, estas son las tres áreas críticas que es necesario evaluar dentro de su organización antes de prepararse para hacer un proyecto de BI: 

1. El nivel de compromiso y el patrocinio del proyecto de la alta dirección
2. El nivel de actividad necesario para crear una implementación de BI
3. La cantidad y calidad de los datos de negocios.

Datos semi-estructurados y no estructurados

Las empresas a crear una enorme cantidad de información valiosa en forma de correos electrónicos, memorandos, notas de call-centers, noticias, material de los grupos de usuarios, chats, informes, páginas web, presentaciones, archivos de imágenes, archivos de vídeo, y la comercialización y noticias. Según Merrill Lynch, más del 85% de toda la información empresarial que existe en estas formas. Este tipo de información se llaman ya sea de datos semi-estructurados y no estructurados. Sin embargo, las organizaciones suelen utilizar estos documentos sólo una vez. 
La gestión de los datos semi-estructurados es reconocido como un problema importante sin resolver en la industria de tecnología de la información.  Según las proyecciones de Gartner (2003), los trabajadores de cuello blanco pasará de 30 a 40 por ciento de su tiempo a buscar, encontrar y la evaluación de los datos no estructurados. BI utiliza tanto los datos estructurados y no estructurados, pero la primera es fácil de buscar, y el segundo contiene una gran cantidad de la información necesaria para el análisis y la toma de decisiones.  Debido a la dificultad de forma adecuada buscar, encontrar y evaluar los datos no estructurados o semi-estructuradas, las organizaciones no pueden recurrir a estas vastas reservas de información, lo que podría influir en una decisión particular, tarea o proyecto. Esto puede dar lugar a la toma de decisiones mal informadas. 
Por lo tanto, en el diseño de una inteligencia de negocios / DW-solución, los problemas específicos asociados a los datos semi-estructurados y no estructurados se deben acomodar a, así como aquellos para los datos estructurados. 

Los datos no estructurados frente a los datos semi-estructurados

Los datos no estructurados y semi-estructurados tener diferentes significados según el contexto. En el contexto de los sistemas de base de datos relacional, se refiere a datos que no pueden ser almacenados en columnas y filas . Debe ser almacenado en un BLOB (objeto binario grande), un cajón de sastre tipo de datos disponibles en la mayoría de bases de datos relacionales sistemas de gestión.
Pero muchos de estos tipos de datos, como e-mails, archivos de texto de texto, PPT, archivos de imágenes, y archivos de vídeo se ajustan a un estándar que ofrece la posibilidad de metadatos. Los metadatos pueden incluir información como el autor y el momento de la creación, y esto puede ser almacenada en una base de datos relacional. Por lo tanto, puede ser más exacto hablar de esto como documentos semi-estructurados o los datos, pero no hay consenso específica parece haber sido alcanzado.

Problemas con los datos semi-estructurados y no estructurados

Hay varios retos para el desarrollo de BI con datos semi-estructurados. De acuerdo con Inmon y Nesavich, Algunos de ellos son:

1. Acceder físicamente a los datos no estructurados de texto - los datos no estructurados se almacena en una gran variedad de formatos.
2. Terminología - Entre los investigadores y analistas, hay una necesidad de desarrollar una terminología estandarizada.
3. Volumen de datos - Como se indicó anteriormente, hasta el 85% de todos los datos existe como datos semi-estructurados. A esto le añadimos la necesidad de palabra a palabra y el análisis semántico.
4. De búsqueda de datos no estructurados textual - Una simple búsqueda en algunos datos, por ejemplo, manzana, da lugar a enlaces en los que se hace referencia a este término de búsqueda más precisas. (Inmon y Nesavich, 2008) da un ejemplo: "se realiza una búsqueda en el delito de plazo. En una búsqueda simple, el delito se utiliza el término, y en todas partes hay una referencia a delito grave, un golpe a un documento estructurado se hace. Sin embargo, una simple búsqueda es crudo. No encontramos referencias a la delincuencia, incendios, asesinatos, malversación de fondos, homicidio vehicular, y tal, a pesar de que estos crímenes son los tipos de delitos. "

El uso de metadatos

Para resolver los problemas con búsquedas y evaluación de datos, es necesario saber algo sobre el contenido. Esto puede hacerse mediante la adición de contexto a través del uso de metadatos . Muchos de los sistemas ya la captura de algunos metadatos (por ejemplo, nombre, autor, tamaño, etc), pero lo más útil sería la de metadatos sobre el contenido real - por ejemplo, resúmenes, temas, personas o empresas mencionadas. Dos tecnologías diseñadas para la generación de metadatos sobre el contenido son categorización automática y extracción de información .