sábado, 22 de febrero de 2014

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. 


domingo, 9 de febrero de 2014

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.



domingo, 26 de enero de 2014

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
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.
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.


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:


Normalizacion - 3FN

La Tercera Forma Normal (3FN)



La tercera forma normal (3NF) es una forma normal usada en la normalización de bases de datos. La 3NF fue definida originalmente por E.F. Codd en 1971. La definición de Codd indica que una tabla está en 3NF si y solo si las dos condiciones siguientes se mantienen:

  • La tabla está en la segunda forma normal (2NF)
  • Ningún atributo no-primario de la tabla es dependiente transitivamente de una clave primaria

Cada atributo debe representar un hecho acerca de la clave, la clave entera, y nada excepto la clave. La versión 3NF de la definición es más débil que la variación de BCNF de Date, pues el anterior se refiere solamente a asegurarse de que los atributos no-clave son dependientes en las claves. Los atributos primarios (que son claves o partes de claves) no deben ser funcionalmente dependientes en absoluto; cada uno de ellos representa un hecho sobre la clave en el sentido de proporcionar parte o toda la clave en sí misma. Debe ser observado que esta regla se aplica solamente a los atributos funcionalmente dependientes, Ya que aplicándola a todos los atributos prohibiría implícitamente claves de candidato compuestas, puesto que cada parte de cualquiera de tales claves violaría la cláusula de "clave completa".


Dependencia transitiva:


Dada la relación R(x, y, z) en la que existen las siguientes dependencias funcionales:
X® y
y® z
se dice que z tiene una dependencia transitiva respecto a x a través de y.

Mediante el grafo de dependencias podemos encontrar de forma fácil las dependencias transitivas





Ejemplo:


Sea la relación R(codigo_alumno,nombre,curso,aula), con las siguientes dependencias funcionales:
Codigo_alumno®nombre,curso;
Curso®aula;

Con la consiguiente tabla:

                                   R
Código_alumno
Nombre
Curso
Aula
1
Marcos
Informática
Aula A
2
Lucas
Inglés
Aula B
3
Marta
Contabilidad
Aula C


Realizamos su grafo de dependencias que es tal que así:




   
1.-Suponemos que la tabla está en 1FN (por los datos de la tabla lo está) y comprobamos que esta en 2FN. Pero existe dependencia funcional transitiva por lo cual no está en 3FN. D

2.-Aplicamos descomposición sin pérdidas para la dependencia que impide la 3FN. Obtenemos:

R1(curso,aula)

R2(codigo_alumno,nombre,curso)


Estas dos relaciones se encuentran en 3FN y se conservan las dependencias funcionales de la relación original R, pues en R2 se mantiene Codigo_alumno®nombre y con la unión de las dependencias de R2 Codigo_alumno®curso y R1 curso®aula  se mantienen la dependencia  Codigo_alumno®curso®aula.


Quedándonos las tablas normalizadas hasta 3FN:

TABLA R1
Curso
Aula
Informática
Aula A
Inglés
Aula B
Contabilidad
Aula C


TABLA R2

Código
Nombre
Curso
1
Marcos
Informática
2
Lucas
Inglés
3
Marta
Contabilidad

Fallas de la 3FN:




Ejemplo
Un ejemplo de una tabla 2NF que falla en satisfacer los requerimientos de la 3NF es:

Ganadores del torneo
TorneoAñoGanadorFecha de nacimiento del ganador
Indiana Invitational1998Al Fredrickson21 de julio de 1975
Cleveland Open1999Bob Albertson28 de septiembre de 1968
Des Moines Masters1999Al Fredrickson21 de julio de 1975
Indiana Invitational1999Chip Masterson14 de marzo de 1977




La única clave candidata es {Torneo, Año}.

La violación de la 3NF ocurre porque el atributo no primario Fecha de nacimiento del ganador es dependiente transitivamente de {Torneo, Año} vía el atributo no primario Ganador. El hecho de que laFecha de nacimiento del ganador es funcionalmente dependiente en el Ganador hace la tabla vulnerable a inconsistencias lógicas, pues no hay nada que impida a la misma persona ser mostrada con diferentes fechas de nacimiento en diversos registros.
Para expresar los mismos hechos sin violar la 3NF, es necesario dividir la tabla en dos:

Ganadores del torneo
TorneoAñoGanador
Indiana Invitational1998Al Fredrickson
Cleveland Open1999Bob Albertson
Des Moines Masters1999Al Fredrickson
Indiana Invitational1999Chip Masterson
Fecha de nacimiento del jugador
JugadorFecha de nacimiento
Chip Masterson14 de marzo de 1977
Al Fredrickson21 de julio de 1975
Bob Albertson28 de septiembre de 1968
Las anomalías de actualización no pueden ocurrir en estas tablas, las cuales están en 3NF.