Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Tarea 3 Ayudantía

426 views

Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

Tarea 3 Ayudantía

  1. 1. Facultad de Ciencias Económicas y Administrativas<br />Instituto de Administracion<br />Escuela de Auditoría<br />Nombre: Cecilia Ayala<br />Elizabeth Muñoz<br />Pabla Rivas<br />Profesor: Cristian Salazar<br />Ayudante: José Luis Carrasco<br />Fecha: 30 de Noviembre del 2010<br />INTRODUCCION<br />EL presente informe contiene el desarrollo de diferentes actividades relacionadas con los principales conceptos y diseños de un Data Warehouse. <br />Primeramente se presentará un marco conceptual y posteriormente un diseño con relación al Data Warehouse.<br />Business Intelligence <br />Business Intelligence es la habilidad para transformar los datos en información, y la información en conocimiento, de forma que se pueda optimizar el proceso de toma de decisiones en los negocios.<br />El término  inteligencia empresarial (en inglés, Business Inteligence)  se refiere al uso de datos en una empresa para facilitar la toma de decisiones. Abarca la comprensión del funcionamiento actual de la empresa, bien como la anticipación de acontecimientos futuros, con el objetivo de ofrecer conocimientos para respaldar las decisiones empresariales.<br />Las herramientas de inteligencia se basan en la utilización de un sistema de información de inteligencia que se forma con distintos datos extraídos de los datos de producción, con información relacionada con la empresa o sus ámbitos y con datos económicos.<br />Por ejemplo: el Pentaho Business Intelligence <br />ERPs <br />Los sistemas de planificación de recursos empresariales (en inglés ERP, Enterprise Resource Planning) son sistemas de gestión de información que integran y automatizan muchas de las prácticas de negocio asociadas con los aspectos operativos o productivos de una empresa.<br />Los sistemas ERP son sistemas integrales de gestión para la empresa. Se caracterizan por estar compuestos por diferentes partes integradas en una única aplicación. Estas partes son de diferente uso, por ejemplo: producción, ventas, compras, logística, contabilidad (de varios tipos), gestión de proyectos, GIS (sistema de información geográfica), inventarios y control de almacenes, pedidos, nóminas, etc. Sólo podemos definir un ERP como la integración de todas estas partes. <br />El ERP integra todo lo necesario para el funcionamiento de los procesos de negocio de la empresa. No podemos hablar de ERP en el momento que tan sólo se integra uno o una pequeña parte de los procesos de negocio. La propia definición de ERP indica la necesidad de "Disponibilidad de toda la información para todo el mundo todo el tiempo".<br />Por ejemplo el software como SAP, ORACLE, SONDA, JDEDWARDS, los cuales se pueden adquirir o arrendar.<br />ETL<br />Extract, Transform and Load (Extraer, transformar y cargar en inglés, frecuentemente abreviado a ETL) es el proceso que permite a las organizaciones mover datos desde múltiples fuentes, reformatearlos y limpiarlos, y cargarlos en otra base de datos, data mart, o data warehouse para analizar, o en otro sistema operacional para apoyar un proceso de negocio.<br />Los procesos ETL también se pueden utilizar para la integración con sistemas heredados.<br />Interfaz Web<br />Las interfaces web tienen ciertas limitaciones en las funcionalidades que se ofrecen al usuario. Hay funcionalidades comunes en las aplicaciones de escritorio como dibujar en la pantalla o arrastrar-y-soltar que no están soportadas por las tecnologías web estándar. Los desarrolladores web generalmente utilizan lenguajes interpretados (scripts) en el lado del cliente para añadir más funcionalidades, especialmente para ofrecer una experiencia interactiva que no requiera recargar la página cada vez (lo que suele resultar molesto a los usuarios). <br />Interfaz Cliente-Servidor<br />La arquitectura cliente-servidor sustituye a la arquitectura monolítica en la que no hay distribución, tanto a nivel físico como a nivel lógico.<br />La red cliente-servidor es aquella red de comunicaciones en la que todos los clientes están conectados a un servidor, en el que se centralizan los diversos recursos y aplicaciones con que se cuenta; y que los pone a disposición de los clientes cada vez que estos son solicitados. Esto significa que todas las gestiones que se realizan se concentran en el servidor, de manera que en él se disponen los requerimientos provenientes de los clientes que tienen prioridad, los archivos que son de uso público y los que son de uso restringido, los archivos que son de sólo lectura y los que, por el contrario, pueden ser modificados, etc. Este tipo de red puede utilizarse conjuntamente en caso de que se este utilizando en una red mixta.<br />Modelos de Datos<br />Es una colección de herramientas conceptuales para describir los datos, las relaciones que existen entre ellos, semántica asociada a los datos y restricciones de consistencia.<br />ER (Entidad Relacion)<br />Denominado por sus siglas como: E-R; Este modelo representa a la realidad a través de entidades, que son objetos  que existen y que se distinguen de otros por sus características.<br />Las entidades pueden ser de dos tipos:<br />Tangibles: Son todos aquellos objetos físicos que podemos ver, tocar o sentir.<br />Intangibles: Todos aquellos eventos u objetos conceptuales que no podemos ver, aun sabiendo que existen, por ejemplo: la entidad materia, sabemos que existe, sin embargo, no la podemos visualizar o tocar.<br />Las características de las entidades en base de datos se llaman atributos, por ejemplo el nombre, dirección teléfono, grado, grupo, etc. son atributos de la entidad alumno; Clave, número de seguro social, departamento, etc., son atributos de la entidad empleado. A su vez una entidad se puede asociar o relacionar con más entidades a través de relaciones.<br />Por ejemplo: un alumno se distingue de otro por sus características particulares como lo es el nombre, o el numero de control asignado al entrar a una institución educativa, así mismo, un empleado, una materia, etc. <br />UML (Lenguaje de Modelado Unificado)<br />UML, por sus siglas en inglés,Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. <br />UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.<br />Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.<br />Ejemplo de UML:<br />Diagrama de Caso de Uso, es uno de los tipos de diagrama en UML que sirve para modelar aspectos dinámicos de sistemas. Como también lo son: los Diagramas de Actividad; Diagramas de Estados, Diagramas de Secuencia y Diagramas de colaboración.<br />Ejemplo de un Diagrama de Uso: “Registro de Hospedaje”<br />43815201295<br />OO (Orientado a Objetos)<br />Es una base de datos inteligente. Soporta el paradigma orientado a objetos almacenando datos y métodos, y no sólo datos. Está diseñada para ser eficaz, desde el punto de vista físico, para almacenar objetos complejos. Evita el acceso a los datos; esto es mediante los métodos almacenados en ella. Es más segura ya que no permite tener acceso a los datos (objetos); esto debido a que para poder entrar se tiene que hacer por los métodos que haya utilizado el programador. <br />DESPCRIPCIÓN DE CADA ETAPA DEL DISEÑO DE UN DATAWAREHOUSE<br />Cualquier metodología de diseño de Data Warehouse debe seguir las fases clásicas del diseño de base de datos: Análisis, diseño y implementación.<br />El diseño de un Data Warehouse consta de cinco etapas, las cuales se describen a continuación:<br />ANÁLISIS DE REQUISITOS: En esta etapa se debe considerar una diversidad de necesidades o requerimientos, los cuales son conducidos por el negocio y por la tecnología. La cuidadosa selección y especificación de requerimientos en esta etapa proporciona un proyecto cimentado que arroja resultados con rapidez. <br />El análisis consiste en determinar la forma en que se cubrirán los requisitos y se enfoca principalmente en la conversión de especificaciones de requerimientos a especificaciones de metamodelo para el Data Warehouse. Después estas especificaciones se usan para generar extractores del Data Warehouse y Software de transformación, integración, resumen y adición. <br />DESEÑO CONCEPTUAL: Los requerimientos de información identificados durante la anterior fase proporcionarán las bases para realizar el diseño del Data Warehouse.<br />El diseño conceptual tiene por objetivo la construcción de una descripción abstracta y completa del problema. Comienza con el análisis de requerimientos de los usuarios y de reglas de negocio, y finaliza con la construcción de un esquema conceptual expresado en términos de un modelo conceptual.<br />Los trabajos existentes en diseño conceptual para DWs corresponden fundamentalmente a modelos de datos. [Cab98], [Gol98a], [Leh98a], [Sap99a], [Fra99], [Car00], [Hus00]. Dichos modelos de datos son modelos multidimensionales que expresan la realidad en términos de dimensiones y medidas. <br />En una primera fase se seleccionan los objetos relevantes para la toma de decisiones, y se especifica el propósito de utilizarlos como dimensiones y/o medidas. <br />En el enfoque basado en requerimientos se analizan los requerimientos de los usuarios, y se identifican en ellos los hechos, dimensiones y medidas relevantes. La realidad se modela como un conjunto de cubos multidimensionales, que se obtienen a partir de los hechos, dimensiones y medidas identificados.<br />Para relevar los requerimientos se depende de la experiencia del diseñador y de entrevistas a los usuarios; es una fase poco automatizable. <br />Los trabajos de diseño conceptual que siguen este enfoque parten de un relevamiento de requerimientos ya realizado y proponen modelos para formalizarlos.<br />En el enfoque basado en las bases fuentes se construyen cubos multidimensionales transformando un esquema conceptual de las bases fuentes. Como modelo conceptual de las fuentes, en general se utiliza el modelo E/R. Las diferentes metodologías comienzan por identificar en el esquema fuente los posibles hechos relevantes para la toma de decisiones. A partir de los hechos identificados navegan por las entidades y relaciones construyendo las jerarquías de las dimensiones.<br />DISEÑO LÓGICO: La etapa de diseño lógico toma como entrada un esquema conceptual y genera un esquema lógico relacional o multidimensional. <br />La dificultad principal es encontrar un esquema lógico que satisfaga no sólo los requerimientos funcionales de información, sino también requerimientos de performance en la realización de consultas complejas de análisis de datos. Esto tiene particular impacto en el caso de usarse bases relacionales, ya que las consultas de análisis de datos incluyen operaciones muy costosas para DBMS relacionales. <br />El resultado de esta etapa es la especificación formal de un esquema lógico para el DW. <br />DISEÑO FÍSICO: La etapa de diseño físico define principalmente los aspectos físicos de almacenamiento de datos, como el almacenamiento de las estructuras lógicas en diferentes discos o la configuración de los servidores de bases de datos que mantienen el almacén de datos.<br />IMPLEMENTACIÓN: La implantación de un Data Warehouse lleva implícitos los siguientes pasos:<br />Extracción de los datos del sistema operacional y transformación de los mismos.<br />Carga de los datos validados en el Data Warehouse. Esta carga deberá ser planificada con una periodicidad que se adaptará a las necesidades de refresco detectadas durante las fases de diseño del nuevo sistema.<br />Explotación del Data Warehouse mediante diversas técnicas dependiendo del tipo de aplicación que se dé a los datos:<br />Query & Reporting<br />On-line analytical processing (OLAP)<br />Executive Information System (EIS) ó Información de gestión<br />Decision Support Systems (DSS)<br />Visualización de la información<br />Data Mining ó Minería de Datos, etc.<br />La información necesaria para mantener el control sobre los datos se almacena en los metadatos técnicos (cuando describen las características físicas de los datos) y de negocio (cuando describen cómo se usan esos datos). Dichos metadatos deberán ser accesibles por los usuarios finales que permitirán en todo momento tanto al usuario, como al administrador que deberá además tener la facultad de modificarlos según varíen las necesidades de información.<br />Con la finalización de esta fase se obtendrá un Data Warehouse disponible para su uso por parte de los usuarios finales y el departamento de informática.<br />MODELOS DE DATA WAREHOUSE<br />STAR SCHEMA (ESQUEMA ESTRELLA): Las tablas en data Warehouse son organizadas lógicamente en un esquema denominado Star Schema, el cual consiste en una tabla central “fact” que contiene los datos que pueden ser analizados en una variedad de formas, y una tabla “dimensión” para cada dimensión, conteniendo datos referenciales. Los datos detallados son almacenados en las tablas de dimensiones y son refereciadas por llaves foráneas en la tabla fact.<br />Por ejemplo, un esquema estrella que pueda soportar el ejemplo consistiría de una tabla “fact”, rodeada de tres tablas “dimensión”, una para productos, otra para ventas regionales, y otra para intervalos mensuales:<br />Fact Table:<br />SALE SUMMARY (Product, Month, región, Sales)<br />Product -> PRODUCT(PID)<br />Month -> MONTH_INTERVAL(Month)<br />Region -> REGIONAL_SALES(RegionNo)<br />Dimension Tables:<br />PRODUCT (PID, PNAME, PCategory, PDescription)<br />REGIONAL_SALES (Region, County, City)<br />MONTH_INTERVAL(MonthNo, Month, Year)<br />En el esquema estrella, las tablas de dimensión pueden no estar normalizadas, conteniendo datos redundantes. La motivación de esta redundancia es incrementar la eficiencia del procesamiento de querys a través de la eliminación de operaciones de join entre tablas.<br />Por otra parte, una tabla desnormalizada puede crecer enormemente, causando un overead que podría contrarrestar cualquier ganancia en el procesamiento de querys. En estos casos las tablas de dimensión pueden ser normalizadas y descompuestas en tablas más pequeñas, refereciándolas en la tabla de dimensión original. Esta descomposición lleva a un modelo de estrella jerárquico denominado Snowflake Schema.<br />SNOWFLAKE SCHEMA (Esquema en copos de nieve)<br />Esquema en copo de nieve (bola de nieve) es una variedad más compleja del esquema estrella. El afinamiento está orientado a facilitar mantenimiento de dimensiones. Lo que distingue a la arquitectura en copo de nieve del esquema estrella, es que las tablas de dimensiones en este modelo representan relaciones normalizadas (3NF) y forman parte de un modelo relacional de base de datos. Con varios usos del esquema en bola de nieve, el más común es cuando las tablas de dimensiones están muy grandes o complejos y es muy difícil representar los datos en esquema estrella. Por ejemplo, si una tabla dimensional de los clientes (CUSTOMERS) contiene un million de filas, sería una idea buena crear una tabla con grupos de clientes (CUSTOMER_GROUPS) y mover los datos comunes para cada grupo de clientes a esta tabla. El tamaño de estas dos tablas será mucho menor que de una tabla no normalizada con todos los datos de clientes. <br />El problema es que para extraer datos de las tablas en esquema de copo de nieve, a veces hay que vincular muchas tablas en las sentencias SQL que puede llegar a ser muy complejo y difícil para mantener. <br />Un ejemplo del esquema en copos de nieve: <br />DISEÑO DE UN DATA WAREHOUSE<br />Empresa: Deloitte <br />Deloitte presta servicios profesionales en auditoría, impuestos, consultoría y asesoramiento financiero a organizaciones públicas y privadas de diversas industrias. Con una red global de firmas miembro en más de 140 países, Deloitte brinda su experiencia y profesionalismo de clase mundial para ayudar a sus clientes a alcanzar el éxito desde cualquier lugar del mundo en el que éstos operen.<br />Los más de 168.000 profesionales de la Firma están comprometidos con la visión de ser modelo de excelencia; están unidos por una cultura de cooperación basada en la integridad y el valor excepcional a los clientes y mercados, en el compromiso mutuo y en la fortaleza de la diversidad. Disfrutan de un ambiente de aprendizaje continuo, experiencias retadoras y oportunidades de lograr una carrera en Deloitte.  Sus profesionales están dedicados al fortalecimiento de la responsabilidad empresarial, a la construcción de la confianza y al logro de un impacto positivo en sus comunidades.<br />Si un cliente se encuentra con un problema en un territorio que no le sea familiar, Deloitte tiene la flexibilidad y las personas para responder a ello in situ, porque el objetivo de nuestra red mundial de firmas miembro es servir a los clientes donde se necesite, profesional y operacionalmente. <br />Unidad de negocio seleccionada:<br />Auditoria<br />Modelo Data warehouse<br />El modelo seleccionado es el STAR SCHEMA (ESQUEMA ESTRELLA, donde se muestra un esquema lógico de estrella y que tiene como centro una tabla llamada Fact la cual contiene los datos que pueden ser analizados. <br />Hemos escogido esta unidad de negocio en particular por que tiene relación con nuestra carrera y porque es de interés saber el proceso y los componentes básicos que están involucrados en un proceso de Auditoria, por factores como el tiempo, el departamento involucrado en la auditoria, el puesto que se relaciona con el cargo de la persona a cargo y por último la empresa que es el cliente al cual se le esta dando el servicio de auditoria.<br />Además, el modelo de Data Warehouse nos da otra perspectiva para el análisis de auditorias, este modelo puede ser normalizado y descompuesto en tablas mas pequeñas, siempre referenciándose en la tabla de dimensión original.<br />Se plantea también que el tiempo de respuesta del servidor es mas rápido debido a que se involucran menos tablas en los Querys, con el modelo estrella aunque una de sus desventajas es que hay que realizar mayor programación, ya que los programas que están en este caso en las punta de las estrellas son más difíciles de mantener<br />TABLA DE HECHOSEmpresaID: intAreaID: intDepartamentoID: intPuestoID: intTiempoID: intAuditoriaID: intAuditorias_Abiertas: Money Auditorias_Cerradas: MoneyAuditorias_en_planeacion: MoneyAuditorias_programadas: MoneyAuditoria_en_Ejecucion: MoneyPuntos_auditados: MoneyNo_Conformidades: MoneyAcciones_Correctivas: MoneyAreaID: intAreaCve: varchar (20)Area: varchar (60)DepartamentoID: intDepartamentoCve: Varchar (20)Departamento: Varchar (60)EmpresaID: intEmpresaCve: varchar (20)Empresa: Varchar (60)PuestoID: intPuestoCve: varchar (20)Puesto: Varchar (30)TiempoID: intFecha: DatetimeAño: char (6)Mes: char (6)Semana: char (6)AuditoriaID: intAuditoriaCve: varchar (20)Auditoria: Varchar(60)<br />CONCLUSIÓN<br />Al analizar el presente trabajo nos damos cuenta cual importante es manejar los conocimientos con respecto al Data Warehouse, ya que nos permite como profesionales, tomar las decisiones correctas y de esta forma beneficiar a las organizaciones en las cuales participemos.<br />El Data Warehouse es una herramienta que nos ayuda a visualizar los problemas reales y las oportunidades para la organización y a través de este trabajo y con las unidad de negocio elegido pudimos profundizar nuestro conocimiento en un ámbito de gran interés para nuestra profesión.<br />

×