Mostrando entradas con la etiqueta BI. Mostrar todas las entradas
Mostrando entradas con la etiqueta BI. Mostrar todas las entradas

viernes, abril 26, 2013

Data Warehouse – Almacén de datos

Data Warehouse – Almacén de datos


Tenía que hacer una pequeña exposición/presentación sobre Data Warehouse en mi diplomado de Gestion TI. He puesto aquí algunos puntos de interés que he considerado.

Data Warehouse

Un Data Warehouse es una colección de datos en la cual se encuentra integrada la información de la Institución y que se usa como soporte para el proceso de toma de decisiones de una administración.
El soporte al procesamiento informático provee de una plataforma sólida, a partir de los datos históricos para hacer análisis.
Facilita la integración de sistemas de aplicación no integrados. Organiza y almacena los datos que se necesitan sobre una amplia perspectiva de tiempo.
Como características importantes de un buen Data Ware house:
  • Flexible, ha de permitir cualquier tipo de dato de la organización y de cualquier fecha (tiempo).
  • Escalable, no sabemos cuánto puede llegar a crecer una organización, por ello el sistema debe de ser lo suficientemente escalable para crecer sin problemas.
  • Orientado a temas, el DW esté integrado con la lógica del negocio es imprescindible.
  • Integrado, uno de los aspectos más importantes del DW es que la información encontrada interna esté siempre integrada.
  • Amigable, debe de ser simple de usar y fácil de acceder a el, sin estas premisas, los usuarios no lo empleará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.
Cabe destacar que, para ampliar un negocio, se necesita que la información sea comprensible y accesible por todos.
Como esquema resumido del funcionamiento un Data Warehouse:


Consideración en plan de sistemas

Un Data Warehouse no se puede comprar, tiene que ser construido a medida y dependiendo de la complejidad de la organización o de los datos existentes, este puede ser muy complicado de implementar e influir mucho en el tiempo necesario para su desarrollo.
Estamos hablando de un proceso con altos beneficios a largo plazo, pero muy costoso de implementar. La total aprobación desde la dirección es imprescindible (top-down), para no tener que estar justificando gastos.
Es importante tener un equipo preparado para la implementación, ya que existe un alto grado de fracaso del proyecto. Por ello se recomienda una implementación por iteraciones.
Antes de comenzar se recomienda un pequeño desarrollo piloto, para demostrar los beneficios de esta práctica, de este modo los usuarios potenciales podrán entender la tecnología y probar los aportes que ofrece.
Por lo tanto, considerar que un Data Warehouse implica una serie de riesgos que se han de considerar en todo plan de sistemas, ya que involucra grandes recursos (dependiendo dimensión del proyecto).

Buenas prácticas derivadas

El flujo de datos que comenzará a manejar la empresa debe de ser analizado.
Gracias a la organización de los datos, la administración debería obtener ventaja estratégica frente la competencia. La experiencia y la evolución que se obtiene gracias a los datos es el mayor beneficio de cara al plan de empresa. Como claro resultado será la obtención de mejores decisiones en el negocio, más oportunidades y más claridad de trabajo.
Continuar con el desarrollo de sofisticación y uso del Data Warehouse, conseguiría que los datos acumulados dentro de una empresa llegarán a ser más organizados, más conectados, más accesibles y, en general, más disponibles a más empleados.
Otra buena práctica derivada sería enlazar el Data Warehouse a otros sistemas (tanto internos como externos a la organización), se puede compartir información con otras entidades comerciales con poco esfuerzo.

viernes, septiembre 02, 2011

Soluciones OpenSource - Que ofrece y como utilizar cada una de las soluciones

Tomado de: Soluciones OpenSource



-
Pentaho
Introducción:
     Pentaho es la solución de business intelligence open source líder a nivel mundial. Permite la creación de almacenes de datos, realizar todo tipo de cuadros de mando, Análisis dimensional de información, KPI's, etc. Pentaho es una suite completa que cubre todos los ámbitos necesarios para una solución B.I.
     Pentaho se consolidó como empresa en el 2004 y desde entonces no ha parado de crecer. Basada en productos exitosos ya pre-existentes Pentaho ha agrupado y empaquetado todos los elementos necesarios para construir nuestra solución B.I.
Componentes:
  • Servidor Business Intelligence: Aplicación web que nos permite explotar nuestros datos de una forma totalmente visual e integrada
  • Consola de Administración del Servidor BI : Consola de administración que nos proporcionará la gestión de nuestro servidor.
  • Herramientas Cliente / De Desarrollo: Conjunto de herramientas que nos permitirán desarrollar nuestra solución:
    • Data Integration: Nos permitirá construir nuestro almacén de datos.
    • Report Designer: Cuya utilidad se centra en la construcción de informes.
    • Metadata Editor: Con la que se modelarán los metadatos.
    • Design Studio: Utilizada para el desarrollo de procesos avanzados.
    • Schema Workbench: Para editar los esquemas Mondrian que serán las bases de nuestros cubos OLAP.
Versión actual:
      La versión actual para la suite completa es la 3.6. Aunque Data Integration y Schema workbench siguen su propia numeración (4.0.1 y 4.0 respectivamente)
Para que sirve:
  • Crear un almacén de datos unificado donde comparar y analizar toda la información disponible en su organización. Integrar toda la información existente en los diferentes sistemas en un único repositorio común que facilite su explotación analítica por los usuarios de dirección o márquetin sin que por ello sufran los sistemas operacionales.
  • Acceder a toda la información de forma visual a través de cuadros de mando interactivos que presentan la información que necesitas cuando la necesitas.
  • Navegar por los datos de su empresa hasta llegar a la información que necesitas.
  • Tener la información actualizada de forma totalmente automatizada.
  • Compartir la información entre departamentos e incluso con el exterior de forma totalmente securizada y controlada.
-
Intalio BPM
Introducción:
     Intalio es uno de los líderes en cuanto a gestión de procesos de negocio (BPM) open source, además de una de las compañías que están haciendo realidad el cloud computing.
      Esta herramienta permite diseñar y gestionar procesos de negocio de forma automatizada. Por ejemplo, cuando llega una factura,permite que esta, se almacene en el lugar adecuado,se envie una copia al departamento de contabilidad y se cree una nueva entrada en el registro de facturas,para que pueda ser validada por un responsable con un simple click.
Componentes:
  • Intalio BPM Designer: Entorno de desarrollo de procesos de negocio, 100% gráfico.
  • Intalio Server: Aplicación web que corre en cualquier servidor de aplicaciones J2EE y que da soporte para la gestión y presentación de los procesos de negocio.
-
Liferay
Introducción:
     Liferay es EL PORTAL CORPORATIVO con mayúsculas y con razón. Liferay permite gestionar todo tipo de contenidos, proporciona herramientas de colaboración online e integración con casi cualquier cosa que se comunique en la web.
     La herramienta fue creada en el año 2000 como portal open source basado en la tecnología J2EE. Pero ya en el año 2004 fue necesario crear Liferay Inc. empresa encargada de gestionar la creciente demanda corporativa del portal Liferay, proporcionando soporte y certificación empresarial sobre el mismo.
     Liferay, gracias a las especificaciones de Java Portlets (1 y 2), permite desarrollar e integrar cualquier tipo de contenido con casi cualquier lenguaje (Java, php, asp, .NET, Ruby, etc) integrando en un único portal corporativo todos los recursos informacionales de su organización bajo un lema que podría ser; "Usted preocúpese del contenido, que yo me ocupo de cómo mostrarlo"




-
Alfresco
Introducción:
     Alfresco, fundado en el 2005 es el gestor de contenidos y documental open source líder del mercado.
      Es una herramienta, basada en tecnología J2EE, que permite gestionar múltiples tipos de información (documentos, wikis, videos, audios, blogs, foros, etc) de múltiples formas (individualizada, de forma colaborativa, compartida en sitios comunes o privados, etc)
Componentes:
  • Gestor documental.
  • Gestor Workflow sobre los contenidos informacionales.
  • Gestor de blog, wiki y foros.
  • Gestor de la información en sitios públicos o privados.



-
Open Bravo
Introducción:
     Openbravo es uno de los ERP y POS (Point Of Sale) Open Source líderes del mercado orientado a la pequeña y mediana empresa. Openbravo es una solución totalmente web. No necesita de la instalación de ningún software en los terminales clientes y ofrece una solución ERP y POS 100% funcional.
     Openbravo ERP incorpora muchas ingeniosas características que le hacen destacarse entre la multitud y le convierten en el perfecto software para empresas.

  • Alertas.
  • Elementos vinculados.
  • Informes dimensionales.
  • Exportación.
  • Correo electrónico.





Componentes:
  • Gestor de compras.
  • Gestor de almacenes.
  • Gestor de la producción.
  • Gestor de ventas.
  • Gestor de servicios.
  • Gestor financiero.



-
Sugar CRM
Introducción:
     Sugar CRM, es el CRM Open Source por excelencia. Es una aplicación para la gestión integral de las relaciones de la organización. El uso típico es la gestión de las relaciones con los clientes aunque, evidentemente se pueden gestionar cualquier otro tipo de relaciones (proveedores, socios, oportunidades, etc)
Componentes:
     Sugar CRM es una aplicación web realizada con PHP. Toda la interacción se realiza con la web, desde el uso normal, como el diseño de nuevos módulos y componentes.




jueves, diciembre 02, 2010

Cómo no construir un datawarehouse

Tomado de:
Creando un DW

A través de TodoBI he encontrado un artículo muy interesante de Ralph Kimball (¿Algún despistado que no lo conoce?) donde detalla los 12 errores más comunes en la construcción de un datawarehouse.
Se trata de un artículo excelente. Cada vez que he cometido alguno de estos errores, he tenido que rectificar al poco tiempo. No valen los atajos, hay que hacer las cosas bien desde el principio.
Los doce errores más comunes en la construcción de un datawarehouse son:
  • Error 12: Incluir atributos de texto en una tabla de hechos, si se hace con la intención de filtrar o agrupar.
  • Error 11: Abreviar las descripciones en las tablas de dimensión con la intención de reducir el espacio requerido.
  • Error 10: Dividir las jerarquías y los niveles de las jerarquías en múltiples dimensiones.
  • Error 9: No afrontar el tratamiento de las dimensiones lentamente cambiantes.
  • Error 8: Crear “smart keys” para relacionar una tabla de dimension con una tabla de hechos.
  • Error 7: Añadir dimensiones en una tabla de hechos antes de definir su granularidad.
  • Error 6: Crear un modelo dimensional para resolver un informe en particular.
  • Error 5: Mezclar hechos de diferente granularidad en una misma tabla de hechos.
  • Error 4: Olvidarse del máximo nivel de detalle en el modelo entidad-relación.
  • Error 3: Omitir las tablas agregadas y comprimir las tablas de dimension para afrontar los problemas de rendimiento.
  • Error 2: No unificar los hechos entre distintas tablas de hechos
  • Error 1: No compartir dimensiones entre diferentes tablas de hechos.
En mi vida laboral he participado en la construcción de varios datawarehouses, y he visto muchos de estos errores. Durante los próximos días, analizaré una a una estas recomendaciones de Kimball, e intentaré justificar por que son errores graves y cómo debemos evitarlos.
A mis lectores menos "tekies", os pido perdón porque los próximos mensajes no los escribo pensando en vosotros. Van dirigidos al lado oscuro... :-)

Serie sobre cómo construir un datawarehouse

Finalmente, he terminado de recorrer la lista de Ralph Kimball sobre cómo no construir un datawarehouse. A lo largo de estos artículos he intentado introducir los conceptos más importantes relativos a la modelización de un datawarehouse (base de cualquier entorno Business Intelligence).
Para finalizar esta serie, incluyo el índice de todas las entradas:
Cada artículo, analiza uno de los 12 errores que justificaron esta serie:
  • Mistake 12: Place text attributes in a fact table if you mean to use them as the basis of constraining and grouping.
  • Mistake 11: Limit the use of verbose descriptive attributes in dimensions to save space.
  • Mistake 10: Split hierarchies and hierarchy levels into multiple dimensions.
  • Mistake 9: Delay dealing with a slowly changing dimension (SCD).
  • Mistake 8: Use smart keys to join a dimension table to a fact table.
  • Mistake 7: Add dimensions to a fact table before declaring its grain.
  • Mistake 6: Declare that a dimensional model is "based on a specific report."
  • Mistake 5: Mix facts of differing grain in the same fact table.
  • Mistake 4: Leave lowest-level atomic data in E/R format.
  • Mistake 3: Eschew aggregate fact tables and shrunken dimension tables when faced with query performance concerns
  • Mistake 2: Fail to conform facts across separate fact tables.
  • Mistake 1: Fail to conform dimensions across separate fact tables.
Y que traduje de esta manera...
  • Error 12: Incluir atributos de texto en una tabla de hechos, si se hace con la intención de filtrar o agrupar.
  • Error 11: Abreviar las descripciones en las tablas de dimensión con la intención de reducir el espacio requerido.
  • Error 10: Dividir las jerarquías y los niveles de las jerarquías en múltiples dimensiones.
  • Error 9: No afrontar el tratamiento de las dimensiones lentamente cambiantes.
  • Error 8: Crear "smart keys" para relacionar una tabla de dimension con una tabla de hechos.
  • Error 7: Añadir dimensiones en una tabla de hechos antes de definir su granularidad.
  • Error 6: Crear un modelo dimensional para resolver un informe en particular.
  • Error 5: Mezclar hechos de diferente granularidad en una misma tabla de hechos.
  • Error 4: Olvidarse del máximo nivel de detalle en el modelo entidad-relación.
  • Error 3: Omitir las tablas agregadas y comprimir las tablas de dimension para afrontar los problemas de rendimiento.
  • Error 2: No unificar los hechos entre distintas tablas de hechos
  • Error 1: No compartir dimensiones entre diferentes tablas de hechos.