Curso de Modelado Dimensional y Modelado del Negocio usando Esquema Estrella

Curso de Modelado Dimensional - Capitulo 6 KLC

Introduccion:

En este capítulo se identifica una serie de cuestiones de modelado tridimensionales avanzados y se proporcionan guías específicas para el manejo de cada situación. La primera sección trata de un conjunto extendido de tabla de dimensiones y diseños, en la segunda sección se describen problemas específicos de tabla de hechos. En la última sección se analizan algunas de las más difíciles preguntas posibles en un entorno de data warehouse.

Tablas de Dimension Extendida:

En esta seccion se describe un numero de situaciones comunes de modelado dimensional en las cuales la construccion de su estructura puede ser de una manera efectiva, y tambien se plantea la situacion en la cual esta estructura puede ser construida de manera equivocada.

• Dimension Mucho-a-Mucho: En una serie de situaciones de diseño clásico de la existencia y el grano de la tabla de hechos es fácilmente entendible y muy fundamental la existencia de cada una de las dimensiones adjuntas a los registros de la tabla de hechos es obvio y no controversial. Pero una de las dimensiones puede legítimamente tener muchos valores. A menudo, la dimensión infractor puede legítimamente tener cero, uno, o muchos valores para un registro dado. El número de valores de la dimensión de tal registro hecho no es cognoscible antes de crear el registro de la tabla hecho. En cierto sentido, el número de valores para esta dimensión es un hecho medido. Llamamos a este tipo de medida a muchos-a-muchos. 
• El problema para el diseñador es qué hacer por ejemplo con la dimensión del diagnóstico de un paciente de un hospital. Los pacientes a veces tienen más de un diagnóstico. Los pacientes realmente enfermos en un hospital pueden tener como hasta diez diagnósticos. Para manejar este carácter abierto, no podemos añadir varias dimensiones de diagnóstico en el esquema. No sabemos lo que la cota superior extrema es para el número de diagnósticos, pero tal esquema sería difícil de consultar. O se une a través de las dimensiones son un anatema para los sistemas relacionales y del SQL Agrupar por falla lógica.
• Dimension Mucho-a-uno-a-Mucho: Vale la pena señalar que hay algunas situaciones sencillas donde lo que parece ser obvio en las combinaciones entre las tablas no devuelven los resultados correctos en cualquier sistema relacional. Considere el caso en el que los clientes desean crear pedidos de productos, y los mismos clientes devolver los productos. Hay una relación de uno a varios entre los clientes y el orden, y otra relación uno-a-muchos entre el cliente y el retorno. Las órdenes y las tablas de rendimientos se supone que tienen diferentes cardinalidades. En otras palabras, no todos los retorno se corresponde exactamente con una sola orden. 
• Parecería obvio que para crear un informe mostrando los pedidos y devoluciones por parte del cliente se deben unir las mesas entre sí. Esta unión simultánea no devuelve la respuesta correcta en un sistema relacional de gestión de base de datos (DBMS). Afortunadamente, este problema se puede evitar fácilmente. nosotros simplemente emitimos multipass SQL y consultamos la tabla de pedidos y la tabla de rendimientos en separadas consultas, exterior a participar en los dos conjuntos de respuestas sobre el encabezado de fila del cliente.
• Dimension Juego de Role: Un role en un almacén de datos es una situación en la que aparece una sola dimensión en varias ocasiones en la misma tabla de hechos. Esto puede suceder en un número de maneras. Por ejemplo, en ciertos tipos de tablas de hechos, el tiempo pueden aparecer repetidamente. Por ejemplo, podemos construir una tabla de hechos para registrar el estado y la disposición final de un pedido de un cliente. Este tipo de tabla de hechos es llamada tabla de hechos instantánea acumulando. 
• El uso de un role embebido, como la ubicación, en una variedad de dimensiones más grandes no relacionados, es uno de los pocos lugares en los que nos animan y apoyan a snowflaking. En otras palabras, nos recomendaría la creación de una unión de cada una de las tablas que se necesitan para describir la ubicación de un clon de la tabla de ubicación. Nosotros necesitamos vistas separadas para cada uso de la tabla de ubicación, con cuidado para crear nombres de las columnas distinguibles. Estos puntos de vista se utilizan después para unirse a sus respectivas dimensiones más grandes, como el número de teléfono de trabajo.

Tabla de echos Extendida:

En esta sección se describe una serie de situaciones en que un modelo común de tabla de hechos es muy eficaz o por el contrario, donde el diseñador puede elegir un diseño ineficiente.

• Datos de diferente granularidad y asignación: El modelo dimensional gana poder como los registros de hechos individuales se vuelven más y más atómica. En el nivel más bajo de transacción individual o individuo instantáneo en el tiempo, el diseño es más potente porque:
• Más de los atributos descriptivos tienen valores únicos. 
• El diseño soporta con gracia sorpresas en forma de nuevos hechos, nuevas dimensiones, o nuevos atributos dentro de las dimensiones existentes. Estos nuevos elementos de datos por lo general se pueden añadir al diseño existente sin desentrañar los procedimientos administrativos existentes o consultas e informes existentes. 
• Por lo general, más expresividad al nivel más bajo de granularidad, y, por tanto, más dimensiones tienen sentido en este nivel. Por ejemplo, a menudo se puede conectar una dimensión empleado a una transacción de cliente que representa el empleado, el cliente agente o el oficial de préstamo, pero esta dimensión empleado no puede tener sentido lógico en un registro resumen mensual o a través de múltiples clientes.

           

 Cuando el diseñador se enfrenta a hechos de diferente granularidad, la primera respuesta debe ser para tratar de obligar a todos los hechos hasta el nivel más bajo. Podemos referirse ampliamente a esta procedimiento que "la asignación de" lo hechos de alto nivel para el nivel bajo. Hay muchos, muchos ejemplos de la necesidad de asignar en un almacén de datos. El ejemplo más generalizado es la necesidad de asignar los costos. Por ejemplo, en una factura de envío, puede haber un envío costaría para toda la factura que en un principio no se ha asignado a la partida individual.

• Hora del día: El seguimiento a escala fina de las transacciones individuales podrá introducir una fecha y un tiempo significativo para estampar en los datos que están disponibles para ese minuto o incluso ese segundo. En este caso, lo que hacemos es no crear una dimensión de tiempo con un registro por cada minuto o segundo en la totalidad. Por lo general, las nociones de día son muy distintas de las nociones de tiempo dentro de la día. La medida del día está virtualmente expresada como una clave sustituta a una dimensión de pleno derecho de la tabla día que contiene la información del calendario. Pero la medida de tiempo de día puede ser mejor expresado como un hecho numérico simple en lugar de como una dimensión, a menos que haya descripciones textuales de ciertos períodos dentro de días que son significativas, como la comida Hora o Graveyard Shift. La hora del día se debe expresar como un número de minutos o número de segundos desde la medianoche.

ROLAP avanzado, consultas e informes:

En esta sección se discuten una serie de técnicas avanzadas para realizar consultas e informes que se han convertido en importantes para una discusión más básica de consultas e informes en un entorno dimensional.

• Drill-Across, consultas con múltiples tecnologías: Después de haber hecho la afirmación de que al conformarse dimensión y conforme hechos, podemos atar mercados de datos dispares, tenemos que echar un vistazo a exactamente cómo se hace eso. Está claro que si damos un paso lo suficientemente atrás y consideramos mercados de datos implementados en diferentes DBMS y datos, incluso a distancia marts implementados en varios OLAP propietaria plataformas, no hay manera para poner en marcha un único de consulta basada en SQL para cualquier máquina y obtener una respuesta conformada a través de estilo drill-across.
• Para hacer drill-across a través de múltiples tecnologías de consulta, hay que poner en marcha una serie de consultas uno contra el mercado de datos y llevar a los resultados separados que establece de nuevo a una plataforma intermedia, donde atamos las respuestas mediante la realización de una especie de combinación de correspondencia en los encabezados de fila de los conjuntos de respuestas.
• Analisis de la cesta de Mercado: Análisis de la cesta del mercado consiste en darse cuenta de las combinaciones de productos que se venden juntos. Aunque muchos análisis de la cesta de mercado son, literalmente, el análisis de la tienda de comestibles cestas de mercado tienda, el concepto se puede ampliar fácilmente a otras situaciones. A diferentes pero perfectamente buen ejemplo es la compra de televisión por cable realizadas en el mes tras la compra de un paquete de visualización de deportes.
• El secreto de la realización de análisis de la cesta de mercado de manera eficiente es empezar en la parte superior de la jerarquía de mercancías y comenzar subdividirlo, con el objetivo de siempre equilibrar el número de cestas en cada grupo.

Modelado del Negocio usando Esquema Estrella - Capitulo 7 Pentaho Solutions

Introduccion:

Cuando se trabaja con los datos del almacén de datos, lo más probable es que los esquemas en estrella se utilicen para entregar los datos al usuario final. No directamente, sin embargo, por regla general, una herramienta de informes o análisis se utiliza para acceder a los datos, mientras más avanzado los usuarios pueden utilizar una herramienta de consulta directa. Sin embargo, es importante señalar que esquemas de estrella son el vehículo de elección si se trabaja con un estilo de Kimball.

Que es un modelo Estrella?

Lo primero que cabe preguntarse es: ¿Por qué estos modelos de base de datos se llaman ''estrella''? Probablemente porque el diagrama entidad-relación de este tipo de esquema se asemeja a una estrella. El centro de la estrella se compone de una tabla de hechos grandes y las puntas de la estrella son las tablas de dimensiones. La mayoría de los usuarios encuentran por primera vez una estrella esquema en un mercado de datos de ventas con los clientes, los productos, las tiendas, las promociones, y tiempo.

Tendremos una visión multidimensional de un proceso que medimos a través de unas métricas. A nivel de diseño, consiste en una tabla de hechos (lo que en los libros encontraremos como fact table) en el centro para el hecho objeto de análisis y una o varias tablas de dimensión (dimension table) por cada dimensión de análisis que participa de la descripción de ese hecho. En la tabla de hecho encontramos los atributos destinados a medir (cuantificar) el hecho: sus métricas. Mientras, en las tablas de dimensión, los atributos se destinan a elementos de nivel (que representan los distintos niveles de las jerarquías de dimensión) y a atributos de dimensión (encargados de la descripción de estos elementos de nivel). En el esquema en estrella la tabla de hechos es la única tabla del esquema que tiene múltiples joins que la conectan con otras tablas (foreign keys hacia otras tablas). El resto de tablas del esquema (tablas de dimensión) únicamente hacen join con esta tabla de hechos. Las tablas de dimensión se encuentran además totalmente denormalizadas, es decir, toda la información referente a una dimensión se almacena en la misma tabla. 

Razones a favor del modelo Estrella:

Este esquema es ideal por su simplicidad y velocidad para ser usado en análisis multidimensionales (OLAP, Datamarts, EIS). Permite acceder tanto a datos agregados como de detalle.

El diseño de esquemas en estrella permite implementar la funcionalidad de una base de datos multidimensional utilizando una clásica base de datos relacional (más extendidas que las multidimensionales).

Otra razón para utilizar los esquemas en estrella es su simplicidad desde el punto de vista del usuario final. Las consultas no son complicadas, ya que las condiciones y las uniones (JOIN) necesarias sólo involucran a la tabla de hechos y a las de dimensiones, no haciendo falta que se encadenen uniones y condiciones a dos o más niveles como ocurriría en un esquema en copo de nieve. En la mayoría de los casos son preferibles los de estrellas por su simplicidad respecto a los de copo de nieve por ser más fáciles de manejar.

Finalmente, es la opción con mejor rendimiento y velocidad pues permite indexar las dimensiones de forma individualizada sin que repercuta en el rendimiento de la base de datos en su conjunto.

Modelado Dimensional y Data Warehouse

Modelado Dimensional - Capitulo 6 KLC

Introducción:

Luego de pasar por un proceso de Análisis y levantamiento de requerimientos como primera fase de la metodología kimball, es necesario realizar un diseño lógico y físico del repositorio de datos. Para la realización de este diseño es recomendable la utilización de un modelado dimensional de manera que estos datos puedan ser  encontrados por los usuarios de una manera intuitiva y rapida. En el capitulo 6 del libro de KLC se estará explicando el uso del modelado dimensional de tal manera de explicar su funcionamiento ventajas y la diferencia que tiene contra del modelo entidad-relación.

Modelo Dimensional:

       El modelado dimensional es una forma de acercar los datos a la manera en que estos serán convertidos en información útil para los usuarios del negocio. La aplicación del modelo dimensional tiene lugar en la fase de diseño lógico, lo que permite la traducción del esquema resultante del diseño conceptual al plano lógico. El modelo dimensional se describe en el año 1996 por Ralph Kimball, como propuesta para el diseño de almacenes de datos (Data Warehouses), partiendo de la visión multidimensional que los usuarios tienen de los datos empresariales cuando se enfrentan a ellos con propósito de análisis (de análisis multidimensional –OLAP– en concreto).

El análisis multidimensional consiste en analizar los datos que hacen referencia a hechos, sean económicos o de otros tipos, desde la perspectiva de sus componentes o dimensiones (utilizando para ello algún tipo de métrica o medida de negocio).Este modelo tiene en cuenta que para el análisis multidimensional los datos se representan como si estuvieran en un espacio n-dimensional (cubo de datos), permitiendo su estudio en términos de hechos sujetos al análisis (facts, en inglés) y dimensiones que permiten diferentes puntos de vista por los que analizar esos hechos.
El modelo dimensional distingue tres elementos básicos:

• Hechos: es la representación en el data warehouse de los procesos de negocio de la organización. Por ejemplo: una venta puede identificarse como un proceso de negocio. Los hechos se podrán reconocer además porque siempre tienen asociada una fecha, y una vez registrados no se modifican ni se eliminan (para no perder la historia).
• Métrica: son los indicadores de negocio de un proceso de negocio. Aquellos conceptos cuantificables que permiten medir nuestro proceso de negocio. Por ejemplo, en una venta tenemos el importe de la misma y la cantidad vendida. Existen métricas derivadas, como el precio unitario, que se obtiene al dividir el importe total por las unidades vendidas.
• Dimensión: es la representación en el data warehouse de un punto de vista para los hechos de cierto proceso de negocio. Si regresamos al ejemplo de una venta, para la misma tenemos el cliente que ha comprado, la fecha en la que se ha realizado, el producto vendido,… Estos conceptos pueden ser considerados como vistas para este proceso de negocio. Puede ser interesante recuperar todas las compras realizadas por un cliente, o para un producto o familia de productos, o para un lapso determinado.

Las Fortalezas de Modelado Dimensional:

El modelo tridimensional tiene un número de importantes ventajas de almacenamiento de datos que el modelo entidad-relación carece. En primer lugar, el modelo dimensional es un framework estandar predecible. Los escritores de informes, herramientas de consulta e interfaces de usuario pueden todos hacer fuerte suposiciones sobre el modelo tridimensional para que las interfaces de usuario sea más comprensible, y para hacer un proceso más eficiente.

 Por ejemplo , ya que casi todos las limitaciones establecidas por el usuario final proceden de las tablas de dimensiones, una herramienta de usuario final puede proporcionar alto rendimiento "navegar " a través de los atributos de una dimensión a través del uso de índices de bit de vector. Los metadatos pueden usar la cardinalidad conocida de valores en una dimensión para guiar el comportamiento de la interfaz de usuario. 

El uso de un optimizador de costos, basado en un motor de base de datos puede hacer suposiciones muy fuertes sobre el primer restringir en las tablas de dimensiones, y luego "atacar" a la tabla de hechos de una sola vez con el producto cartesiano de esas claves de tabla de dimensiones que satisfacen las restricciones del usuario. Sorprendentemente, en el uso de este enfoque es posible evaluar la N-maneras arbitrarias donde se une a una tabla de hechos en una sola pasando por el índice de la tabla de hechos. Estamos tan acostumbrados a pensar en la n-forma se une como "hard" que toda una generación de administradores de BD no se dan cuenta de que el n-maneras de unirse al problema es formalmente equivalente a un único tipo de combinación.

La relación entre el modelado tridimensional y modelado Entidad-Relación:

La clave para entender la relación entre el modelado tridimensional y la entidad-relación es que un solo diagrama entidad-relación se descompone en realidad múltiple diagramas de mesa. Piense en un gran diagrama entidad-relación como la representación de todos los posible de procesos de negocio en la empresa. El diagrama entidad-relación maestro puede tener llamadas de ventas, entrada de pedidos, facturas de envío, los pagos de los clientes y de productos devoluciones, todos en el mismo diagrama. En cierto modo, el diagrama entidad-relación en sí flaquea al representar en un diagrama de múltiples procesos que no conviven en datos individuales establecidos en un solo punto en el tiempo coherente. No es de extrañar que el diagrama entidad - relación es demasiado complejo. Así, el primer paso en la conversión de un diagrama de entidad-relación a un conjunto de diagramas de modelado dimensional es para separar el diagrama de entidad-relación en sus procesos de negocio discretos y modelar cada uno por separado.

El segundo paso es seleccionar los muchos-a-muchos en el modelo entidad-relación que contiene hechos que no son clave numérica y aditivos, y designarlos como tablas de hechos. 

El tercer paso es desnormalizar todas las tablas restantes en tablas planas con una sola pieza que se conectan directamente a las tablas de hechos. Estas tablas se convierten en las tablas de dimensiones. En los casos en que una tabla de dimensiones se conecta a más de una tabla de hechos, representamos a esta misma tabla de dimensiones en ambos esquemas, y nos referimos a las tablas de dimensiones como  "Conformada" entre los dos modelos dimensionales.

Data Warehouse - Capitulo 6 Pentaho Solutions

Introducción:

       En un almacén de datos lo que se quiere es contener datos que son necesarios o útiles para una organización, es decir, que se utiliza como un repositorio de datos para posteriormente transformarlos en información útil para el usuario. Un almacén de datos debe entregar la información correcta a la gente indicada en el momento óptimo y en el formato adecuado. El almacén de datos da respuesta a las necesidades de usuarios expertos, utilizando Sistemas de Soporte a Decisiones (DSS), Sistemas de información ejecutiva (EIS) o herramientas para hacer consultas o informes. Los usuarios finales pueden hacer fácilmente consultas sobre sus almacenes de datos sin tocar o afectar la operación del sistema.

     Como define textualmente Ralph Kimball la definición de almacén de datos como:  "una copia de las transacciones de datos específicamente estructurada para la consulta y el análisis". 

       Ahora tenemos que enfocar la importancia de tener un data warehouse dentro de una organización, dando como beneficio final el darle al usuario una búsqueda de datos de manera intuitiva y rápida.

Por que tener un Data Warehouse dentro de una Organizacion?

      Las personas que nunca han estado expuestos al concepto de un almacén de datos,

a menudo se confunden acerca de la necesidad y el propósito de una base de datos especializada para fines de soporte de decisiones. Incluso después de que los datos son integrados, que son beneficios obvios de diferentes sistemas, el rendimiento de las consultas, los sistemas de código de alivio de consultas de larga ejecución y el seguimiento de la historia, se han explicado que no siempre está claro por qué la construcción de un almacén de datos es una buena idea. Bastante a menudo, estos usuarios se han acostumbrado a la recuperación o la obtención de datos de varias fuentes, incluyendo los datos que se les envió por e-mail, que luego de importación en una aplicación de hoja de cálculo que se utilizan para su posterior análisis y presentación de informes. 

No es necesario un data warehouse, ¿verdad? No es tan cierto, de hecho. Vamos a tratar de explicar por qué un almacén de datos es útil, desde la perspectiva de un usuario:

• Toda la información está en un solo lugar: No más búsqueda bajo varias fuentes dispares de información o tratar de encontrar los archivos más antiguos en un desordenado e-mail sistema o estructura de carpetas. No hay necesidad de ya sea por la combinación de todo estos datos usted mismo, ya está integrado y listo para su uso.
• Hasta a la fecha de la información: los datos en el almacén de datos son automáticamente cargados y actualizados de forma regular, lo que significa que nunca está fuera de fecha o vera la información antigua.
• Acceso rápido: El almacén de datos está optimizado para una rápida recuperación de la información. El almacén de datos responde a sus consultas mucho más rápido que almacenes de archivos locales o archivos de correo electrónico.
• No hay límites de tamaño: las hojas de cálculo se pueden almacenar sólo una cantidad limitada de datos y menudo tendrá que ser dividido en pedazos para acomodar toda la información requerida. Un almacén de datos puede almacenar una cantidad prácticamente ilimitada de datos así que no hay más la descarga de datos a una base de datos local o una nueva hoja de cálculo es requerida.
• Fácil de entender: El almacén de datos es el modelo en términos de negocio y refleja la forma de ver a su organización. Usted no tiene que descifrar los acrónimos de tres letras que nadie entiende, sino que puede tener nombres claros para todos los elementos de datos.
• Estandarizacion de datos:Todo se ajusta a las normas, lo que significa que hay es sólo una definición y un conjunto de valores para cada pieza de información. Un buen ejemplo de esto es la codificación de género. Algunos sistemas utilizan 0 y 1, un cierto uso de niños / niñas y otros usos M / F / U (para desconocida). todo traducciones a una sola definición estandarizada han sido atendidos.

Esta lista señala las ventajas de un almacén de datos, pero se basa en un 

importante premisa: que el almacén de datos está diseñado y construido correctamente. 

Ciclo de vida de Ralph Kimball

Metodología de Ralph Kimball

La metodología de Kimball, llamada Modelo Dimensional (Dimensional Modeling), se basa en lo que se denomina Ciclo de Vida Dimensional del Negocio (Business Dimensional Lifecycle). Esta metodología es considerada una de las técnicas favoritas a la hora de construir un Data Warehouse.

Un almacén de datos (Data Warehouse) es una colección de datos orientada a un determinado ámbito (empresa, organización, etc.), integrado, no volátil y variable en el tiempo, que ayuda a la toma de decisiones en la entidad en la que se utiliza. Es una estructura de datos donde la información contenida esta diseñada para favorecer el análisis y la divulgación eficiente de datos.

En el Modelo Dimensional se constituyen modelos de tablas y relaciones con el propósito de optimizar la toma de decisiones, con base en las consultas hechas en una base de datos relacional que están ligadas con la medición o un conjunto de mediciones de los resultados de los procesos de negocio.

El Modelo Dimensional es una técnica de diseño lógico que tiene como objetivo presentar los datos dentro de un marco de trabajo estándar e intuitivo, para permitir su acceso con un alto rendimiento.

¿Por qué es necesario construir un Data Warehouse?

Los sistemas de ingreso de transacciones se ven afectados por las consultas a sus bases de datos. Generalmente poseen informes predefinidos, y cualquier modificación a los mismos debe ser solicitado al departamento de sistemas, que será en definitiva quien evaluará si tiene los recursos humanos disponibles como para realizarlos. El Data Warehouse está separado de los sistemas transaccionales, por lo tanto las consultas no afectan la velocidad de registro de las operaciones. Se actualiza periódicamente, capturando datos de los distintos sistemas transaccionales. Una vez implementado, es importante elegir las herramientas de consulta al Data Warehouse, que permitan un alto grado de autonomía a los usuarios.

La pregunta más común con respecto a los Data Warehouses es:

Ya tengo la información en la base de datos, entonces ¿para qué necesito un repositorio adicional?

La respuesta a esto es que la base de datos, o cualquier otro sistema de archivos que está orientado a los sistemas de producción están diseñadas para tener un respuesta rápida a transacciones relativamente pequeñas: Emitir una factura, registrar un cheque, etc. No están orientadas hacia el proceso masivo de información para reportes.

En cambio el Data Warehouse se construye pensado en que tenga una gran capacidad para obtener reportes que involucren el procesamiento de enormes cantidades de información y en el menor tiempo posible.

Fases del ciclo de vida Kimball

• Planificación del Proyecto.

Busca identificar  la definición y el alcance del proyecto de Data Warehouse, las justificaciones del negocio y evaluaciones de factibilidad. Se focaliza sobre recursos, perfiles, tareas, duraciones y secuencialidad.

Es independiente al negocio y sus requerimientos. Esta etapa identifica el escenario del proyecto para saber donde surge la necesidad del Data Warehouse. “Antes de comenzar un proyecto de Data Warehouse o Data Mart, hay que estar seguro si existe la demanda y donde la existe. Si no se tiene un solo usuario sponsor y no hay usuarios entusiasmados posponga el proyecto”.

Algunos factores asociados con esta etapa son:

·         Identificación de los tres Sponsors (usuarios).

·         Convincentes motivaciones del negocio.

·         Cooperación entre áreas y negocios de sistemas.

·         Cultura analítica de la organización y,

·         Análisis de factibilidad.

• Definición de los requerimientos del negocio.

La técnica utilizada para nivelar los requerimientos de los analistas de negocio difiere de los enfoques tradicionalistas guiados por los datos (Inm92) (Gol99). Los diseñadores de los data warehouse deben entender los factores claves que guían al negocio para determinar efectivamente los requerimientos y traducirlos en consideraciones de diseño apropiadas, pues son la base para las tres etapas paralelas subsiguientes focalizadas en la tecnología, los datos y las aplicaciones, por lo cual es altamente critica y el diseño es el centro de atención del BDL (Business Dimensional Lifecyle).

• Modelado dimensional.

Básicamente se comienza con una matriz donde se determina la dimensionalidad de cada indicador y luego se especifican los diferentes grados de detalle (atributos), dentro de cada concepto del negocio (dimensión), así como la granularidad de cada indicador (variable o métrica) y las jerarquías que dan forma al modelo dimensional del negocio (BDM) o mapa dimensional.

• Diseño físico.

El diseño físico se focaliza sobre la selección de estructuras necesarias para soportar el diseño lógico. Los elementos principales de este proceso son la definición de convenciones estándares de nombres y seteos específicos del ambiente de la base de datos. La indexación y las estrategias de particionamiento son también determinadas etapas.

Uno de los problemas del modelado dimensional y a su implementación relacional es el llamado n-way join, el hecho de tener que hacer join de cada lookup contra la BT de una por vez. En algunos RDBMS esto se resuelve mediante el seteo de STAR JOIN en el motor mejorando el rendimiento en unas 60 veces por sobre la utilización del join secuencial en un equipo de iguales características. Esta técnica demanda la realización de un producto cartesiano, algunos motores no la proveen, pero en un modelo dimensional es más eficiente que hacer el join entre lookup´s u BT una a una.

•  Diseño y desarrollo de presentación de datos.

Las principales sub-etapas de esta zona del ciclo de vida son: la extracción, la transformación y la carga (ETL process). Se definen como procesos de extracción a aquellos requeridos para obtener los datos que permitirán efectuar la carga del modelo físico acordado. Los procesos de transformación sirven para convertir o recodificar los datos fuente para cargar el modelo físico. Los procesos de carga de datos sirven para poblar el Data Warehouse. Ralph Kimball propone en esta etapa un PLAN de diez  pasos.

•  Diseño de la Arquitectura Técnica

Los ambientes de data warehousing requieren la integración de numerosas tecnologías. Se debe tener en cuenta tres factores: los requerimientos del negocio, los actuales ambientes técnicos y las directrices técnicas estratégicas futuras planificadas para de esta forma poder establecer el diseño de la arquitectura técnica del ambiente de data warehousing.

Hay que tener un plan antes de comenzar, no es simplemente reoordenar y explotar la información. Al igual que en una contrucción, los planos sirven para comunicar los deseos entre los clientes y el arquitecto, como así también para medir esfuerzos y materiales necesarios para la obra (comunicación, planificación, flexibilidad y mantenimiento, documentación, productividad y reuso).

•  Selección de Productos e Instalación

Utilizando el diseño de arquitectura técnica como marco, es necesario evaluar y seleccionar componentes específicos de la arquitectura como ser la plataforma de hardware, el motor de base de datos, la herramienta de ETL o el desarrollo pertinente, herramientas de acceso, etc.

Una vez evaluados y seleccionados los componentes determinados se procede con la instalación y prueba de los mismos en un ambiente integrado de data warehousing.

•  Especificación de Aplicaciones para Usuarios Finales

Los diferentes roles o perfiles de usuarios determinan la interfase o ventana al warehouse. Herramientas de diseño de reportes y consultas avanzadas para analistas, tableros de control para gerentes, acceso mediante inter/intra net para usuarios internos/externos remotos, envío de información por dispositivos no estándares para usuarios internos/externos, etc.

Se clasifican a los usuarios según su perfil de consulta, desde usuarios con un perfil más estratégico y menos predecibles (power users) hasta usuarios netamente operacionales que consumen una serie de reportes estándares (final users) pasando por los usuarios gerenciales con uso de interfases push-button (EIS users).

•  Desarrollo de Aplicaciones para Usuarios Finales

Siguiendo a la especificación de las aplicaciones para usuarios finales, el desarrollo de las aplicaciones de los usuarios finales involucra configuraciones del metadata y construcción de reportes específicos.

•  Implementación

La implementación representa la convergencia de la tecnología, los datos y las aplicaciones de usuarios finales accesible desde el escritorio del usuario del negocio. Hay varios factores extras que aseguran el correcto funcionamiento de todas estas piezas, entre ellos se encuentran la capacitación, el soporte técnico, la comunicación, las estrategias de feedback. Todas estas tareas deben ser tenidas en cuenta antes de que cualquier usuario pueda tener acceso al data warehouse.

•  Mantenimiento y crecimiento

Data Warehousing es un proceso (de etapas bien definidas, con comienzo y fin, pero de naturaleza espiral) pues acompaña a la evolución de la organización durante toda su historia. Se necesita continuar con los relevamientos de forma constante para poder seguir la evolución de las metas por conseguir. Según afirma Kimball [Kim98], “si se ha utilizado el BDL el data warehouse está preparado para evolucionar y crecer”.

Al contrario de los sistemas tradicionales, los cambios en el desarrollo deben ser vistos como signos de éxito y no de falla. Es importante establecer las prioridades para poder manejar los nuevos requerimientos de los usuarios y de esa forma poder evolucionar y crecer.

Gartner Inc. BI

Gartner Business Intelligence

Gartner Group realiza investigación y análisis para las industrias de hardware computacional, software, comunicaciones y de tecnologías de la información (TI). La empresa está organizada en cuatro segmentos de negocios: investigación, consultoría, eventos y TechRepublic.

Gartner proporciona el análisis de investigación y el consejo para profesionales de las TIC (tecnologías de la información y la comunicación), empresas de tecnología y la comunidad de la inversión en varios formatos: reuniones informativas, servicios de pares en red (peer networking service) y programas de socios diseñados explícitamente para CEOs y otros directores ejecutivos.

Gartner utiliza para presentar sus análisis los conocidos como Cuadrantes Mágicos y los ciclos de sobreexpectación (hype cycle).

Ciclo de sobreexpectacion

Un ciclo de sobreexpectación es una representación gráfica de la madurez, adopción y aplicación comercial de una tecnología específica.

El término fue acuñado por Gartner, una casa de análisis/investigación, basada en los EE.UU., que proporciona opiniones, consejos y datos sobre la industria de las tecnologías de la información mundial.

Cinco Fases:

El ciclo de sobreexpectación de Gartner se compone de cinco fases:

1. "Lanzamiento" - La primera fase de un ciclo es el "lanzamiento", una presentación del producto o cualquier otro evento genera interés y presencia en los medios.
2. "Pico de expectativas sobredimensionadas" - En la siguiente fase, el impacto en los medios genera normalmente un entusiasmo y expectativas poco realistas. Es posible que algunas experiencias pioneras se lleven a cabo con éxito, pero habitualmente hay más fracasos.
3. "Abismo de desilusión" - Las tecnologías entran en el abismo de desilusión porque no se cumplen las expectativas. Estas tecnologías dejan de estar de moda y en consecuencia, por lo general la prensa abandona el tema.
4. "Rampa de consolidación" - Aunque la prensa haya dejado de cubrir la tecnología, algunas empresas siguen, a través de la "pendiente de la iluminación", experimentando para entender los beneficios que puede proporcionar la aplicación práctica de la tecnología.
5. "Meseta de productividad" - Una tecnología llega a la "meseta de productividad", cuando sus beneficios están ampliamente demostrados y aceptados. La tecnología se vuelve cada vez más estable y evoluciona en segunda y tercera generación. La altura final de la meseta varía en función de si la tecnología es ampliamente aplicable y sólo beneficia a un nicho de mercado.

El término se utiliza ahora de forma generalizada en el marketing de las TI

Cuadrante magico de Gartner:

Gartner concibe la ruta de maduración de las compañías orientadas a los datos como aquella que pasa de reportes y consultas “descriptivos”, que detallan condiciones actuales, a análisis y visualizaciones de “diagnóstico”, que revelan por qué el desempeño se rezagó en algunas áreas y alcanzó un nivel de excelencia en otras.

El siguiente paso es hacia la analítica “predictiva”, que indica hacia dónde van las cosas, y finalmente a la analítica “prescriptiva”, que orienta las decisiones para lograr un desempeño óptimo.

El camino correcto para lograr una analitica prescriptiva dentro de una organizacion es que la busqueda de descubrimiento de datos sea mas significativa dentro de la arquitectura BI y analitica. El beneficio de estas herramientas es una mayor agilidad, ya que se libera a los usuarios para que exploren datos y encuentren nueva información sin tener que enviar solicitudes de nuevos cubos o reportes a IT.

El cuadrante magico de Gartner muestra 4 cuadrantes en los cuales estan predefinidos las mas importantes empresas de TI a nivel mundial. Gartner da importancia a las mejores practicas lo cual genera en un futuro cercano ganancias y mayor nivel de competencia dentro del mercado, esto refleja el porque organizaciones pequeñas alcanzan un nivel de liderazco como IBM, Microsoft, SAS, Oracle y SAP.

Analista en Sistemas

Universidad Central de Venezuela

Facultad de Ciencias

Escuela de Computación

Nombre: Luis Leon; CI:18.837.655

v  Informe Técnico sobre el perfil de “Analista en Sistemas”

1.       Resumen:

En el siguiente informe se va a plantear el resultado de una investigación exhaustiva sobre el perfil trabajo que debe cumplir un Analista de Sistema. A través de esta investigación observaremos los requisitos que el mercado laboral solicita, las competencias que se exigen, las tareas que se esperen que se desempeñen dentro del ámbito laboral, entre otros. Para realizar esta investigación se buscara dentro de distintas redes sociales y portales de empleo, de manera que podamos realizar un cuadro comparativo de las diferentes ofertas de empleo que existen actualmente en el mercado.

2.       Introducción:

Para comenzar a trabajar  con la investigación primero se debe tener claramente lo que es un “Analista de Sistema” y las funciones que debe realizar dentro de una organización:

Analista de Sistema: puede referirse al encargado del desarrollo de aplicaciones en lo que respecta a su diseño y obtención de los algoritmos, así como de analizar las posibles utilidades y modificaciones necesarias de los sistemas operativos para una mayor eficacia de un sistema informático. Otra misión de estas personas es dar apoyo técnico a los usuarios de las aplicaciones existentes.

Las funciones o tareas principales de un Analista son las siguientes:

·         El analista tiene como cometido analizar un problema y describirlo con el propósito de ser solucionado mediante un sistema informático.

·         El diseñador realiza, con base en el análisis, el diseño de la solución

·         El analista tiene que delimitar el análisis para ver lo que se quiere hacer inicialmente y después darle al usuario nuevas opciones de uso.

    Ahora con esta información obtenida podemos proceder a realizar una búsqueda en los perfiles de trabajo de diversas compañías y con ellas comparar si realmente estos perfiles buscan y se adecuan a las funciones que debe realizar un analista.

3.     Planteamiento del problema:

Basándonos en la definición de Analista y comparando con investigaciones iniciales los perfiles de algunos portales de empleo, empiezan a aparecer ciertas dudas sobre inconsistencia entre las tareas a realizar y el perfil de búsqueda de una compañía, empiezan a aparecer las siguientes dudas:

·         Realmente las compañías requieren de un analista?. O más bien requieran de habilidades técnicas dentro de su organización?

·         Es fundamental tener más de 2 o 3 años de experiencia laboral para cumplir con un perfil de analista? Y que pasa con los nuevos universitarios recién graduados?

·         Están utilizando las empresas actualmente un sistema metodológico para la creación de un proyecto de TI?

Dados estas inquietudes planteamos un problema que ocurre actualmente dentro de las organizaciones y por el cual se están realizando malas prácticas dentro de un desarrollo lo que conlleva a no completar los objetivos principales de un proyecto.

4.       Cuadro Resumen de competencias del perfil, actividades a realizar ,etc.

Empresa	Descripción	Competencias de perfil	Actividades a Realizar	Conocimiento
Sanitas Venezuela		Que cumplan con el siguiente perfil: Ingeniero en Sistemas, Computación o Informática (Indispensable).		Conocimientos básicos en lenguaje de programación PHP, Jquery. Dominio de programación estructurada y programación orientada a objetos. Conocimientos en SQL y MySql
Occibiz Tecnología	Consultor, analista de sistemas para cumplir funciones inherentes.	Egresados universitarios o TSU en áreas afines		Se requiere que los profesionales a ser contratados sean personas proactivas, responsables, orientadas a entregar soluciones de negocios, con capacidad de aprender en corto tiempo el negocio medular que delineará todas sus actividades; con fuertes actitudes hacia el trabajo, analíticos y organizados.  Con amplia experiencia en Tecnología Oracle y/o Java Empresarial para el desarrollo de proyectos informáticos en nuestros clientes corporativos, de las áreas Banca y Finanzas, Telecomunicaciones, Seguros, y Minería y Petróleo.
Talent Group 2010	Actualmente nos encontramos en la búsqueda de un talento humano altamente capacitado para ocupar la posición de “Analista de Sistemas", con aspiración de crecimiento profesional, capaz de combinar la experiencia con el profundo conocimiento y herramientas de informática, basado en la estrategia de mejora continua.	TSU, Licenciado o Ingeniero en Informática, Computación o Sistemas. Con experiencia de 1 o 2 años comprobada en el área.	Realizar actividades de soporte técnico básico a computadoras y Laptop. Ejecutar configuraciones y manejo de base de datos. Programación en lenguaje C++ y Visual Basic. Planificación, desarrollo y mantenimiento de programas de informática.	Amplios conocimientos en programación (Java, Visual Basic y C++), redes, servidores y manejo de base de datos. Manejo del Inglés intermedio a nivel de lectura y comprensión. Manejo de Office, Windows. Competencias: Organizado, planificado, proactivo y con iniciativa. Puntual, responsable, habilidad para definir prioridades, con clara visión del trabajo en equipo y disposición positiva hacia el trabajo. Es necesario poseer habilidad de lógica y analítica.
Venezolano de Crédito		Ingeniero de Sistemas o Computación 02 Años de Experiencia en puestos similares (no limitativo a la banca)	Realizar mantenimiento y desarrollo de sistema	Java y Técnologia J2EE (Indispensable) Experiencia Java JDK Manejo de JavaServer Pages (JSP) Standard Tag Library (JSTL)/ Servlet Manejo de JDBC Opcional: Frame Work: Struts / Web Services/ XML / Ajax / Java Server Faces.  Oracle SQL y deseable PL/SQL Experiencia en el desarrollo De sistemas

5.       Conclusiones:

Luego de realizar una investigación de distintos perfiles de trabajo para el puesto de Analista de Sistemas se llega a la conclusión de que existe actualmente un problema dentro de las organizaciones y los equipos de desarrollo de TI ya que no están cumpliendo con todas las fases que requieren un desarrollo de proyecto.  No promueven o no dan énfasis a la fase de análisis donde das abstracción del sistema y consigues los requerimientos funcionales y no funcionales de la misma, los cuales te van a llevar a un desarrollo más ágil y terminando en un cumplimiento de todos los objetivos del sistema en el tiempo estimado.

Entonces las empresas actualmente buscan perfiles de Analistas pero se enfocan más en sus aptitudes técnicas que las que tenga como analista de problema, esto  termina siendo un trabajo de desarrollo de sistema y no de analista.

6.       Bibliografía:

v  http://www.empleate.com/venezuela/:

o   http://www.empleate.com/venezuela/ofertas/empleo/757731/analista_de_sistemas_de_apoyo_al_negocio/caracas/

o   http://www.empleate.com/venezuela/ofertas/empleo/759148/consultores_oracle_pl_sql_java/caracas_miranda/

o   http://www.empleate.com/venezuela/ofertas/empleo/758632/analista_de_sistema/caracas/

v  http://www.bumeran.com.ve:

o   http://www.bumeran.com.ve/empleos/analista-de-sistemas-java-venezolano-de-credito-1001454856.html

o   http://www.bumeran.com.ve/empleos/analista-de-sistema-b-amp;g-consultores-corporativos-1001451920.html

v  http://es.wikipedia.org/wiki/Analista_de_sistemas