Diseño y Construcción de Data Warehouse. Instituto de Computación - Facultad de Ingeniería Mayo Diseño Lógico
|
|
- Susana Purificación Río Ortiz
- hace 7 años
- Vistas:
Transcripción
1 Diseño y Construcción de Data Warehouse Instituto de Computación - Facultad de Ingeniería Mayo 2017 Diseño Lógico 2
2 Temario: Diseño Lógico Introducción. Formas de almacenamiento Estrategia a partir de un esquema conceptual. Estrategia a partir de datos fuente. 3 Diseño Lógico Introducción 4
3 Motivación Objetivos del Diseño Lógico del DW. Construir el esquema lógico del DW o DM. Sobre un DBMS Relacional o Multidimensional. Problemas a resolver. Transformaciones de modelos y especificaciones: Esquema Conceptual: abstracto. Esquema Lógico: implementado. Obtener estructuras adecuadas a la función. Tener en cuenta la Carga de Trabajo. 5 Arquitectura típica de SDW [Malinowski 2008] 6
4 Objetivo: el DW Propiedades del DW. Volúmenes importantes de datos. Operación crítica: Consultas interactivas complejas, muy frecuentemente con lógica multidimensional. Actualización: Batch (en lotes). Volúmenes de datos importantes. Los datos pasan por varias transformaciones. Solución depende del Modelo Lógico. Relacional o Multidimensional. 7 Proceso de Diseño Lógico Entradas: Información a representar en el DW. Esquema Conceptual o especificación equivalente. Características de las BD Fuente. Estructura. Características de los datos. Información sobre DW workload (carga de trabajo). o especificación equivalente asociada a requerimientos no funcionales. Salida: Esquema Lógico del DW. 8
5 Proceso de Diseño Requerimientos DW diseño de cubos data marts MD carga diseño conceptual esq. conceptual DW diseño lógico refinamiento esq. lógico relacional DW DW rel. carga esq. conceptual fuentes esq. lógico relacional DW bases fuente esquemas de bases fuente 9 Diseño lógico de DW Enfoques de diseño: Pasaje / traducción del esquema conceptual multidimensional al esquema lógico Diseño a partir de las fuentes 10
6 Diseño Lógico desde Esq. Conceptual Conectar (acercar) la especificación Conceptual al Modelo Lógico. Incorporar requerimientos no funcionales: Operaciones críticas. Frecuencias de operaciones. Volúmenes de datos. Agregar al esquema conceptual: Indicaciones orientadas a reqs no funcionales: Lineamientos de Diseño (Design Guidelines). Mappings a BD Fuentes. Construir estructuras del DW con estos 3 elementos: Esquema Conceptual + Guidelines + Mapping Trabajos existentes: [Gol98b][Cab98][Per01] 11 Diseño Lógico desde BDs Fuente Los requerimientos se asocian a las BD fuente: Qué datos interesa acceder? y con qué performance? Pasos: Seleccionar información en BDs fuentes. Transformar para obtener un esquema de DW con acceso eficiente. Teniendo en cuenta requerimientos no funcionales. Trabajos existentes: Consultas OLAP: [Bal98][Kim96][Mar00][Moo00] Consultas SQL: [Lig99][The99][Wid95][Wu97] 12
7 Diseño Lógico desde BDs Fuente Vistas Materializadas Orientado a consultas SQL para mejorar su performance DW es un conjunto de vistas materializadas El problema de diseño del DW: Entrada: consultas sobre relaciones en bases de datos fuentes Salida: un conjunto seleccionado de vistas a materializar de manera de mejorar la evaluación de las consultas Referencias: [Lig99][The99][Wid95][Wu97] 13 Diseño Lógico Modos de Almacenamiento 14
8 ROLAP DW en BD Relacional (ROLAP) Modelo estandarizado. Tanto en estructura como lenguaje de manipulación (SQL). Flexibilidad y potencial para consultas ad-hoc. Especialmente consultas por clave y por condición. Transformación compleja de datos y operaciones MD hacia estructuras y operaciones Relacionales. Mala performance en Joins y Sumarizaciones. Se ha avanzado mucho en optimización de consultas, índices, joins, etc., para aplicaciones DW. Muchos sistemas comerciales utilizan almacenamiento ROLAP o HOLAP para grandes volúmenes de datos. 15 MOLAP DW en BD Multidimensional (MOLAP) Modelo MOLAP: Datos y operaciones multidimensionales se mapean directamente Almacenan datos en estructuras especializadas. Muy alta performance en consultas dimensionales. Poco usables para consultas por clave o por condición. Muy poco flexibles para actualización: Solo append a la BD (carga incremental). Modelo menos estandarizado. No hay estándares de estructura pero si de lenguaje de consulta (MDX). 16
9 ROLAP - MOLAP Multi-dimensional: Acceso a datos relacionales sólo durante la carga. Adecuado cuando se quiere independencia del DBMS relacional. Mejor performance para sistemas accedidos con mucha frecuencia. Relacional: Menor espacio en disco. Adecuado para grandes conjuntos de datos. Híbrido: Balance entre performance y espacio en disco. Adecuado cuando se accede frecuentemente a datos resumidos y los datos detallados son poco accedidos. 17 Diseño de un DW Relacional Características del DW Acceso y mantenimiento de datos Consultas complejas Se considera solo-lectura. El mantenimiento no se hace vía sistema OLTP, sino en forma "batch". Usuario final accede directamente al DW con herramientas de consulta (OLAP) Modelo Relacional poco adecuado para consultas dimensionales. Implican Joins entre varias tablas y Sumarizaciones, que son costosas y poco optimizables. Técnicas de diseño de DW diferentes a las tradicionales para BDs relacionales 18
10 Diseño de un DW Relacional Modelo Dimensional [Kim96] Orientados a consultas OLAP Se representan los conceptos MD sobre el modelo Relacional. Se trata de minimizar joins y totalizaciones: Redundancia en cálculos. Fuerte tendencia a desnormalizar. Estructuras básicas Tablas de hechos (fact tables) Donde se guardan las medidas numéricas del negocio Granularidad: Intersección de las dimensiones Tablas de dimensión (dimension tables) Donde se guardan las descripciones de las dimensiones Jerarquías: desnormalizadas o normalizadas 19 Esquema estrella - Estructura Tabla central: hechos Conjunto de tablas usualmente con menos registros organizadas alrededor: dimensiones Clientes Fechas Geografía Vendedores Hechos de Ventas Productos 20
11 Esquema estrella - Características Tablas de dimensión. Desnormalizadas y con jerarquías embebidas. Tablas de hechos. Unidas a todas las de dimensión por relaciones 1:N Clave primaria = concatenación de las claves primarias de todas las dimensiones. 21 Esquema Estrella (ejemplo) 22
12 Esquema Estrella: Constelación y Galaxia 23 Esquema Snowflake - Estructura Es el resultado de descomponer una o más tablas de dimensiones en varias tablas, que forman jerarquías. Semanas Meses Departamentos Regiones Clientes Días Ciudades Tipos Sucursales Vendedores Hechos de Ventas Modelos Productos 24
13 Esquema Snowflake - Características Es un Esquema Estrella con las dimensiones normalizadas según las jerarquías que contienen. Construcción a partir del Esquema Estrella Normalizar las jerarquías de cada dimensión. Construcción directa: Una tabla de hechos. Una tabla para cada nivel de una dimensión. Las tablas de los niveles de una misma dimensión se relacionan a través de foreign- keys. 25 Esquema Snowflake - Ejemplo 26
14 Esquema Star Cluster Estructura: Es una combinación de Star y Snowflake. Selectivamente separa los fragmentos de jerarquías compartidos entre diferentes dimensiones. El resto de las jerarquías se desnormalizan. Características: Mínimo número de tablas, y a la vez evita solapamiento entre dimensiones. Referencia: [Moo00] 27 Esquema Star Cluster - Ejemplo 28
15 Diseño de un DW Multidimensional Modelos Multi-dimensionales Orientados a consultas OLAP Se implementan los conceptos MD sobre estructuras MD. Estructuras propietarias. Intuición de estructuras Arrays multidimensionales. Granularidad: Intersección de las dimensiones Dimensiones en los ejes, medidas en las celdas. Unidas a jerarquías de dimensiones por referencias. Jerarquías de dimensiones Árboles de jerarquías (índices) Diccionarios con datos descriptivos. 29 Diseño de un DW Multidimensional Id-Familia Nom-familia F1 Sport F2 Gala F1 F2 P1 P2 P3 P4 Id-producto Nom-producto P1 P2 P3 P4 Remera Pantalón Vestido Traje C1 C2 C3 C4 C5 P P2 P3 P
16 Diseño Lógico Traducción del Esquema Conceptual 31 Proceso de Diseño Requerimientos DW diseño de cubos data marts MD carga diseño conceptual esq. conceptual DW diseño lógico refinamiento esq. lógico relacional DW DW rel. carga esq. conceptual fuentes esq. lógico relacional DW bases fuente esquemas de bases fuente 32
17 Traducción a un esq. lógico Consiste en: Diseñar las BDs a partir de esquemas conceptuales. Problemas a resolver: Ofrecer acceso eficiente y simple. Se deben adaptar los esquemas conceptuales al modelo implementado. Tener en cuenta requerimientos no funcionales 33 Metodología Determinar requerimientos no funcionales: Uso del sistema. Performance requerida. Limitaciones de espacio en disco. Elegir modo de almacenamiento: MD, relacional, híbrido. Definir estrategias de almacenamiento: Por ej. lineamientos de diseño. Adaptar las estructuras a restricciones de las herramientas. 34
18 Almacenamiento Se resuelve almacenamiento de: Dimensiones Relaciones dimensionales Agregaciones Resúmenes pre-calculados (aggregates) Un registro representa un resumen de registros de nivel básico de una tabla de hechos o cubo 35 Traducción a un esq. lógico Ejemplo: Cantidad vendida por cliente por producto. clientes departamento id-departamento# nom-departamento productos ciudad id ciudad# nom-ciudad cliente id cliente# nom-cliente familia id-familia# nom-familia producto id producto# nom-producto ventas cantidad cantidad clientes venta productos ventas 36
19 Traducción a relacional Dimensiones Id-producto Nom-producto P1 Remera P2 Pantalón P3 Vestido P4 Traje Id-Familia F1 F1 F2 F2 Id-Familia Nom-familia F1 Sport F2 Gala familia productos familia id-familia# nom-familia producto id producto# nom-producto producto Id-producto Nom-producto Id-Familia Nom-familia P1 Remera F1 Sport P2 Pantalón F1 Sport P3 Vestido F2 Gala P4 Traje F2 Gala 37 Traducción a relacional clientes departamento id-departamento# nom-departamento Dimensiones Id-cliente Nom-cliente Id-ciudad Nom-ciudad Id-depto Nom-depto C1 Juan 1 Mercedes K Soriano C2 Ana 1 Mercedes K Soriano C3 Pablo 2 Colonia L Colonia C4 José 2 Colonia L Colonia C5 María 3 Carmelo L Colonia ciudad id ciudad# nom-ciudad cliente id cliente# nom-cliente 38
20 Traducción a Id-producto relacional Nom-producto Id-Familia Nom-familia P1 Remera F1 Sport P2 Pantalón F1 Sport P3 Vestido F2 Gala P4 Traje F2 Gala Id-cliente Id-producto Cantidad C1 P1 2 C2 P1 5 C2 P2 1 C3 P3 10 C3 P4 3 C4 P1 4 C5 P3 8 productos Relaciones dimensionales venta clientes ventas Id-cliente Nom-cliente Id-ciudad Nom-ciudad Id-depto Nom-depto C1 Juan 1 Mercedes K Soriano C2 Ana 1 Mercedes K Soriano C3 Pablo 2 Colonia L Colonia C4 José 2 Colonia L Colonia C5 María 3 Carmelo L Colonia 39 Traducción a relacional Agregaciones Id-Familia Nom-familia Id-producto Nom-producto Id-Familia Nom-familia F1 Sport P1 Remera F1 Sport F2 Gala P2 Pantalón F1 Sport P3 Vestido F2 Gala P4 Traje F2 Gala Id-cliente Id-producto Cantidad C1 P1 2 C2 P1 5 Id-ciudad Id-familia Cantidad C2 P2 1 1 F1 8 2 F2 13 C3 P F1 4 C3 P4 3 3 F2 8 C4 P1 4 C5 P3 8 Id-cliente Nom-cliente Id-ciudad Nom-ciudad Id-depto Nom-depto C1 Juan Id-ciudad 1 Nom-ciudad Mercedes Id-depto K Nom-depto Soriano C2 Ana 1 1 Mercedes KK Soriano Soriano C3 Pablo 2 2 Colonia LL Colonia C4 José 3 2 Carmelo Colonia LL Colonia C5 María 3 Carmelo L Colonia 40
21 Traducción a MD productos familia id-familia# nom-familia Dimensiones Id-Familia Nom-familia F1 Sport F2 Gala producto id producto# nom-producto F1 F2 P1 P2 P3 P4 Id-producto Nom-producto P1 Remera P2 Pantalón P3 Vestido P4 Traje 41 Traducción a MD Id-depto K L Nom-depto Soriano Colonia Id-ciudad Nom-ciudad 1 Mercedes 2 Colonia 3 Carmelo K L C1 C2 C3 C4 C5 Id-cliente C1 C2 C3 C4 C5 clientes Dimensiones departamento id-departamento# nom-departamento Nom-cliente Juan Ana Pablo José María ciudad id ciudad# nom-ciudad cliente id cliente# 42
22 Traducción a MD Relaciones dimensionales clientes venta ventas F1 F2 productos P1 P2 P3 P4 K L C1 C2 C3 C4 C5 C1 C2 C3 C4 C5 P P2 P3 P Traducción a MD Agregaciones F1 8 4 F F1 F2 P1 P2 P3 P4 K L C1 C2 C3 C4 C5 C1 C2 C3 C4 C5 P P2 P3 P
23 Estrategias de almacenamiento Lineamientos de Diseño [Per01] Objetivo: Complementar especificación conceptual con indicaciones para resolver requerimientos no funcionales. Tipos de Lineamientos: Materialización de Relaciones Dimensionales. Fragmentación (vertical) de Dimensiones. Fragmentación (horizontal) de Cubos. 45 Lineamientos de Diseño En el proceso de Diseño Lógico. conceptual schema design guidelines refined conceptual schema rules REFINEMENT (task 1) MAPPING (task 2) GENERATION (task 3) DW relational schema source relational schema 46
24 Lineamientos de Diseño Materialización relaciones dimensionales. Permite indicar cubos a materializar, para evitar cálculos, aumentando performance en consultas. Fragmentación (vertical) de dimensiones. Especifica grupos de datos dimensionales a ser almacenados conjuntamente. Impacto en grado de partición/unión en estructuras de datos para dimensiones. Fragmentación (horizontal) de cubos. Permite almacenar por separado datos de igual esquema pero diferente uso. 47 Materialización de Relaciones Dimensionales Introducción: En CMDM, las relaciones dimensionales especifican un conjunto de cruzamientos potenciales, dados por los niveles de las dimensiones. A cada cruzamiento concreto se le denomina Cubo. Definición: Un lineamiento de tipo Materialización de Rel Dim, consiste en la especificación de un Cubo indicando que se quiere almacenar materializado. Ejemplo: fechas clientes venta vendedores articulos cantidades clientes rubro id rubro# rubro cliente id cliente# cliente ciudad id ciudad ciudad mes rubro vendedor venta-1 (venta) articulo cantidades 48
25 Criterios de uso Materialización de Relaciones Dimensionales Se almacena al menos un cubo por relación dimensional Se debería materializar los cubos de mayor granularidad para no perder información Cubos adicionales mejoran la performance de ciertas consultas. Debe balancearse con restricciones de almacenamiento y duración de la carga Prever la materialización de datos no obtenibles de los datos detallados por problemas de aditividad Factores a analizar: Performance necesaria para las consultas Restricciones de almacenamiento Tiempo de duración de la carga 49 Fragmentación Vertical de Dimensiones Introducción. Las Dimensiones consisten habitualmente en jerarquías formadas por múltiples niveles. Incluso pueden consistir en varias jerarquías alternativas. Definición: Un lineamiento de tipo Fragmentación Vertical de Dimensión consiste en la especificación de grupos de niveles de una Dimensión a ser almacenados conjuntamente. Ejemplo: 50
26 Criterios de uso Fragmentación Vertical de Dimensiones. Para obtener mejor performance en estas operaciones se tiende a mantener un único fragmento, pero esto genera redundancia Si los datos de la dimensión cambian muy poco, entonces la redundancia no es un gran problema Si la dimensión cambia frecuentemente y se registran versiones, entonces la redundancia genera problemas de mantenimiento. Jerarquías que no se navegan conjuntamente pueden ser almacenadas por separado Factores a analizar: Performance Tratamiento de la redundancia Requerimientos de navegación por las dimensiones 51 Fragmentación Horizontal de Cubos Introducción. Los Cubos tendrán asociados grandes conjuntos de datos, que comparten el mismo esquema pero pueden ser usados en forma diferente. Definición. Un lineamiento de tipo Fragmentación Horizontal de Cubo consiste en la especificación de bandas o franjas correspondientes a particiones horizontales del conjunto de datos. Ejemplo: Se definen franjas según el mes de Venta: Antes de enero Después de enero
27 Criterios de uso Fragmentación Horizontal de Cubos. Cuantas más franjas se definan, serán de menor tamaño y se obtendrá mejor tiempo de respuesta al consultarlas Por otro lado, si algunas consultas involucran varias franjas, estas operaciones tendrán menos performance Requieren drill-across La redundancia (franjas no disjuntas) debe balancearse con restricciones de almacenamiento Factores a analizar: Tamaño del cubo Subconjunto de registros que son usados juntos frecuentemente Restricciones de almacenamiento 53 Lineamientos: criterios de uso Usando los lineamientos el diseñador define: Cubos para cada RelDim. Franjas para cada Cubo. Fragmentos Verticales para cada Dimensión. Para definirlos debe tener en consideración: Requerimientos de performance y almacenamiento. Volúmenes de datos. Funcionamiento del DBMS utilizado. 54
28 Restricciones de herram. OLAP Principio: Refinar las estructuras de datos no soportadas por el OLAP elegido. Ejemplos: No se soportan jerarquías alternativas: Definir varias dimensiones. No se soportan diferentes roll-ups para medidas: Definir varias medidas, una con cada roll-up. No existe drill-across: Tener medidas redundantes, en varios cubos. 55 Restricciones de herram. OLAP Ejemplo: Dimensiones formadas por una única jerarquía de niveles. Fecha Fecha1 Fecha2 Fecha3 Año Año Año Año Semestre Cuatrimestre Semestre Semestre Cuatrimestre Trimestre Bimestre Trimestre Bimestre Bimestre Mes Mes Mes Mes 56
29 Restricciones de herram. OLAP Ejemplo: Medidas sólo soportan un roll-up por defecto. Tener varias medidas una con cada roll-up. Tener calculadas agregaciones para diferentes roll-ups. Ejemplo: Cantidad en stock: Se quiere sumar por producto. Se quiere promedio o último período por fecha. fechas stock productos Suma-stock Promedio-stock Ultimo-stock 57 Restricciones de herram. OLAP Ejemplo: Cubos formados por un conjunto de niveles y un conjunto de medidas. Implementan una relación dimensional. A veces se fusionan varias relaciones dimensionales para evitar drill-across. Ejemplo: Se desea comparar: Cantidad en stock. Cantidad vendida. fechas stock productos stock ventas 58
30 Resumen: Metodología Determinar requerimientos no funcionales: Uso del sistema. Performance requerida. Limitaciones de espacio en disco. Elegir modo de almacenamiento: MD, relacional, híbrido. Definir estrategias de almacenamiento: Por ej. lineamientos de diseño. Adaptar las estructuras a restricciones de las herramientas. 59 Diseño Lógico Diseño Lógico a partir de las Fuentes 60
31 Proceso de Diseño Requerimientos DW diseño de cubos data marts MD carga diseño conceptual esq. conceptual DW diseño lógico refinamiento esq. lógico relacional DW DW rel. carga esq. conceptual fuentes esq. lógico relacional DW bases fuente esquemas de bases fuente 61 De datos fuentes a DW relacional: una propuesta Enfoque clásico: Star Schema derivado de los requerimientos Problemas del enfoque: No todos los datos se adecuan naturalmente a esta estructura Requerimientos de usuario: base inestable para diseño Si el diseñador no entiende las relaciones subyacentes entre los datos, puede llevar a diseños incorrectos Referencia: [Moo00] 62
32 Ventajas del enfoque Enfoque estructurado para desarrollar el modelo dimensional Asegura que el DW refleja las relaciones subyacentes de los datos Simplifica procesos de extracción y de carga El modelo de datos de la empresa provee la base para identificar los requerimientos de forma bottom-up es una base más estable para el diseño que los requerimientos de usuarios 63 Ejemplo Notación de [Hitchman, 1995] para ER. 64
33 Clasificar entidades 3 categorías: Transaction entity Describe un evento que sucede en un punto en el tiempo. Contiene medidas o cantidades. Component entity Directamente relacionado a una transaction entity via una relación 1:N. Contestan quién, qué, cuándo, dónde, cómo y porqué del evento. Classification entity Son entidades que están relacionadas a las component por una cadena de relaciones 1:N. Representan jerarquías embebidas en el modelo de datos, que podrían ser colapsadas en las component entities para formar las dimensiones en un star schema. 65 Ejemplo/ Clasificación de entidades Entidad transacción Entidad componente Entidad clasificación 66
34 Identificar jerarquías Una jerarquía en un MER puede ser identificada como secuencia de entidades unidas a través de relaciones 1:N, alineadas en la misma dirección. Colapsar una jerarquía (desnormalizar) 67 Producir Modelo Dimensional Cuánto colapsar? Hay una gama de opciones para el modelo dimensional: Flat Schema Terraced Schema Star Schema Snowflake Schema Star Cluster Schema 68
35 Flat Schema Método: Se colapsan todas las entidades hasta las entidades minimales (entidades hoja de la jerarquia). Resultado: Una tabla para cada entidad minimal Problemas: Redundancia en dependencias parciales y transitivas. Pueden haber errores al realizar agregaciones cuando existen relaciones entre transaction entities (Ej.: Sale y Sale Ítem) Minimiza nro. de tablas, incrementa la complejidad de cada tabla 69 Terraced Schema Método: Se forma colapsando entidades en las jerarquías maximales, pero deteniéndose cuando se alcanza una transaction entity. Resultado: Una tabla para cada transaction entity. 70
36 Star Schema Método: Para cada transaction entity, una tabla de hechos. Clave: combinación de las claves de las component entities asociadas. Para cada component entity, una tabla de dimensión. Se colapsan en ella las classification entities que están jerárquicamente relacionadas. Cuando hay relaciones jerárquicas entre transaction entities, la entidad hija hereda todas las dimensiones (y los atr. clave) del padre. Resultado: Un star schema separado para cada transaction entity. 71 Star Schema 72
37 Constellation Schema y Galaxy Constellation: Star schemas cuyas tablas de hecho están relacionadas jerárquicamen te (1-N). Galaxy: Star schemas que comparten dimensiones. 73 Snowflake Schema Método: Una tabla de hechos para cada transaction entity. Cada component entity se transforma en una tabla de dimensión. Las classification entity quedan iguales. Cuando hay relaciones jerárquicas entre transaction entities, la entidad hija hereda todas las dimensiones (y los atr. clave) del padre. Las tablas de hechos con la misma clave primaria son candidatas a ser combinadas. 74
38 Snowflake Schema 75 Star Cluster Schema Problema: Al colapsar totalmente las jerarquías: cuando las jerarquías en diferentes dimensiones se solapan. Hay redundancia y puede haber inconsistencias. Se identifican fork entities : classification entities que tienen multiples relaciones 1:N 76
39 Star Cluster Schema Método: Una tabla de hechos para cada transaction entity. Las classification entities se colapsan con sus jerarquias hasta alcanzar una fork entity o una component entity. Si se alcanzo una fork entity, se forma una tabla de sub-dimension. Consistira de la fork entity mas todos sus ancestros. Cuando hay relaciones jerarquicas entre transaction entities, la entidad hija hereda todas las dimensiones (y los atr. clave) del padre. Es un esquemaquedisminuyeel númerode tablasy a la vezevita solapamiento entre dimensiones. 77 Resumen Pasos Desarrollar modelo de datos de la empresa. Modelo integrado ER Clasificar entidades. Diseñar esquemas dimensionales lógicos. Desarrollar star-cluster schemas para cada transaction entity del modelo. Estos se pueden combinar formando constellations o galaxies. 78
Definición. Data Warehousing: almacenamiento, transformación y distribución de datos útiles para los responsables de tomar decisiones 9/29/2006 4
Definición Data Warehousing: almacenamiento, transformación y distribución de datos útiles para los responsables de tomar decisiones 9/29/2006 4 Definición (cont.) Un Data Warehouse es una colección de
Más detallesDiseño multidimensional. Jordi Conesa i Caralt Isabel Guitart Hormigo M. Elena Rodríguez González
Diseño multidimensional Jordi Conesa i Caralt Isabel Guitart Hormigo M. Elena Rodríguez González Índice Necesidades de los analistas y herramientas OLAP Multidimensionalidad Diseño lógico Necesidades de
Más detallesTÍTULO: BASES DE DATOS Disponibilidad Objetivos 5 Definicion de una base de datos 9 Datos de nomina (tabla) 9 Esquema de bases de datos (mapa
TÍTULO: BASES DE DATOS Pág. Disponibilidad Objetivos 5 Definicion de una base de datos 9 Datos de nomina (tabla) 9 Esquema de bases de datos (mapa conceptual) 10 Datos de venta (tabla) 10 Caracteristicas
Más detallesData Warehousing Diseño e implementación de un data warehouse
Data Warehousing Diseño e implementación de un data warehouse Marta Millan millan@eisc.univalle.edu.co www.eisc.univalle.edu.co/materias Estrategia de división Por qué dividir las tablas?: Facilidad de
Más detallesBodegas de Datos y OLAP. Introducción a la Bodegas de Datos
Bodegas de Datos y OLAP Introducción a la Bodegas de Datos Contenido SI-Definición y Clasificación MIS Vs DSS DSS-Definición y Características DW-Definición, Elementos, Características, Arquitectura, OLTP
Más detallesIntroducción a las Bases de Datos
Introducción a las Bases de Datos Organización lógica de los datos Sistemas basados en archivos Concepto intuitivo de base de datos Sistemas gestores de bases de datos Definición Características y ventajas
Más detallesMSc. Francisco García
REPUBLICA BOLIVARIANA DE VENEZUELA MINISTERIO DEL PODER POPULAR PARA LA DEFENSA UNIVERSIDAD NACIONAL EXPERIMENTAL POLITÉCNICA DE LA FUERZA ARMADA BOLIVARIANA UNEFA NÚCLEO MIRANDA SEDE LOS TEQUES MSc. Francisco
Más detallesConceptos básicos de bases de datos
Conceptos básicos de bases de datos 1.1 Definición de base de datos Una base de datos es una colección de archivos relacionados que permite el manejo de la información de alguna compañía. Cada uno de dichos
Más detallesTÉCNICO SUPERIOR UNIVERSITARIO EN TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN ÁREA SISTEMAS INFORMÁTICOS.
TÉCNICO SUPERIOR UNIVERSITARIO EN TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN ÁREA SISTEMAS INFORMÁTICOS. HOJA DE ASIGNATURA CON DESGLOSE DE UNIDADES TEMÁTICAS 1. Nombre de la asignatura Ingeniería de
Más detallesPrueba de autoevaluación 2
Universidad Carlos III de Madrid1 Prueba de autoevaluación 2 1. En un sistema OLTP: a) El significado de un proceso transaccional está orientado hacia el negocio. b) El significado de un proceso transaccional
Más detallesDesde los programas más simples escritos en un lenguaje de programación suelen realizar tres tareas en forma secuencial.
Tipos de Datos Desde los programas más simples escritos en un lenguaje de programación suelen realizar tres tareas en forma secuencial. Entrada de datos Procesamientos de datos Salida de resultados Los
Más detallesOLAP 2 OLAP 1 OLAP 4 OLAP 3 OLAP 5 OLAP 6
OLAP EXPLOTACIÓN UN DW: EXPLOTACIÓN UN DW:... OLAP 1 OLAP 2 EXPLOTACIÓN UN DW: MOLO UN AMBIENTE OLAP EXPLOTACIÓN UN DW: LAS HERRAMIENTAS OLAP PRESENTAN AL USUARIO UNA VISIÓN MULTIDIMENSIONAL LOS DATOS
Más detallesDecision Support System (DDS)
Sistemas de Soporte a la toma de Decisiones Decision Support System (DDS) Decision Support System (DDS) Son aquellos que, mediante el uso de reglas de procesamiento de datos basadas en lógica, en combinación
Más detallesModelos Multidimensionales con Analysis Services Primeros Pasos
Modelos Multidimensionales con Analysis Services Primeros Pasos Marco Tulio Gómez mgomez@solcomp.com MSc. Tecnologías de la Información MCITP Business Intelligence Developer MCTS Business Intelligence
Más detallesQué es una tabla dinámica? Para qué sirve una tabla dinámica?
Gracias a las múltiples solicitudes de alumnos, me he propuesto realizar este manual a modo de entregar una guía base y una ayuda de memoria para todos aquellos que trabajan con esta herramienta. He decidido
Más detallesLa Base de Datos OLAP Analysis Services (SSAS) Agenda. Agenda. Construyendo una Solución de BI paso a paso con SQL Server 2005
Construyendo una Solución de BI paso a paso con SQL Server 2005 La Base de Datos OLAP Analysis Services (SSAS) Ing. José Mariano Alvarez Jose.Mariano.Alvarez@SqlTotalConsulting.com Agenda Por qué Analysis
Más detalles3. DOCUMENTACIÓN 3.1. DOCUMENTACIÓN DE APLICACIONES. OBJETIVOS PARA MODIFICAR HACE FALTA COMPRENDER/ESTUDIAR:
3. DOCUMENTACIÓN 3.1. DOCUMENTACIÓN DE APLICACIONES. OBJETIVOS UN SISTEMA SOFTWARE QUE SEA: + DIFÍCIL DE COMPRENDER + SÓLO UTILIZABLE POR SUS REALIZADORES + DIFÍCIL DE MODIFICAR NO ES VÁLIDO PARA EVITAR
Más detallesCAPÍTULO 2 DATA WAREHOUSES
CAPÍTULO 2 DATA WAREHOUSES Un Data Warehouse (DW) es un gran repositorio lógico de datos que permite el acceso y la manipulación flexible de grandes volúmenes de información provenientes tanto de transacciones
Más detallesM ÉTODO DE MUESTREO DE GEOSINTÉTICOS PARA ENSAYOS I.N.V. E
M ÉTODO DE MUESTREO DE GEOSINTÉTICOS PARA ENSAYOS I.N.V. E 908 07 1. OBJETO 1.1 Esta práctica cubre dos procedimientos para el muestreo de geosintéticos para ser ensayados. Se requiere que las instrucciones
Más detallesSistemas Operativos. Curso 2016 Sistema de Archivos
Sistemas Operativos Curso 2016 Sistema de Archivos Agenda Interfaz. Archivos. Directorios. Seguridad en archivos. Implementación. Definiciones. Sistema de archivos virtual. Estructura de los directorios.
Más detallesBases de Datos UN IVERSIDAD N AC IONAL D E MISIONES FACULTAD IENCIAS EXACTAS, QUÍMICAS Y NATURALES
CATEDRA: INTRO. BASES DE DATOS PROFESOR: Asc. PAUTSCH, German TITULAR: Ing. CASTAÑO Rubén UN IVERSIDAD N AC IONAL D E MISIONES FACULTAD IENCIAS EXACTAS, QUÍMICAS Y NATURALES Bases de Datos 1. Introducción...
Más detallesDiseño arquitectónico 1ª edición (2002)
Unidades temáticas de Ingeniería del Software Diseño arquitectónico 1ª edición (2002) Facultad de Informática objetivo Los sistemas grandes se descomponen en subsistemas que suministran un conjunto relacionado
Más detallesMateria requisito: DOMINIOS COGNITIVOS (Objetos de estudio, temas y subtemas) I. INTRODUCCION A LAS BASES DE DATOS
UNIVERSIDAD AUTÓNOMA DE CHIHUAHUA Clave: 08MSU0017H Clave:08USU4053W FACULTAD DE INGENIERÍA DES: Ingeniería Programa(s) Educativo(s): Ingeniería en Ciencias de la Computación Tipo de materia: Obligatoria
Más detallesImplementación de herramientas CASE que asistan en el Diseño de Data Warehouses
Implementación de herramientas CASE que asistan en el Diseño de Data Warehouses Verónika Peralta, Raúl Ruggia Universidad de la República, Uruguay. {vperalta, ruggia}@fing.edu.uy Resumen: Un Data Warehouse
Más detallesEste documento enumera los diferentes tipos de Diagramas Matriciales y su proceso de construcción.
DIAGRAMA MATRICIAL 1.- INTRODUCCIÓN Este documento enumera los diferentes tipos de Diagramas Matriciales y su proceso de construcción. Muestra su potencial, como herramienta indispensable para la planificación
Más detallesCapítulo 6. Relaciones. Continuar
Capítulo 6. Relaciones Continuar Introducción Una relación es una correspondencia entre dos elementos de dos conjuntos con ciertas propiedades. En computación las relaciones se utilizan en base de datos,
Más detallesAnalysis Server 2008 Diseño multidimensional. Tecnología OLAP Tutorial
Analysis Server 2008 Diseño multidimensional. Tecnología OLAP Tutorial Marta Zorrilla Universidad de Cantabria 2010 Tabla de contenidos 1. Uso de Microsoft Analysis Services 3 1.1. Cómo crear un cubo OLAP
Más detallesRESUMEN DE LAS DIAPOSITIVAS DE BASE DE DATOS 1
RESUMEN DE LAS DIAPOSITIVAS DE BASE DE DATOS 1 ANTES QUE NADA DEFINIR QUE ES UNA BASE DE DATOS: Una base de datos es una colección estructurada de datos, Un sistema de base de datos es una colección de
Más detallesComputación II. Introducción a Visual Basic
Computación II Introducción a Visual Basic Introducción a Visual Basic Microsoft Visual Basic es un conjunto de herramientas que posibilitan el desarrollo de aplicaciones para Windows de una manera rápida
Más detallesRequerimientos de Software
Requerimientos de Software Ingeniería de Requerimientos Se define como el proceso de establecer los servicios que el consumidor requiere de un sistema y las restricciones sobre las cuales de funcionar
Más detallesAnálisis y Diseño de Sistemas
Análisis y Diseño de Sistemas Dpto. Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Clase 17 Modelo Entidad Relación Lic. María Mercedes Vitturini [mvitturi@cs.uns.edu.ar] 1er. CUATRIMESTRE
Más detallesAmpliación de las funciones docentes:
Ampliación de las funciones docentes: resignificación del currículum y atención a la diversidad gestión institucional interacción con el mundo del trabajo diseño e implementación de situaciones de enseñanza-aprendizaje
Más detallesInteligencia de Negocios
Inteligencia de Negocios Las herramientas de exploración: El análisis multidimensional, el reporte y distribución pro activa. 1 Esquema de la clase 1. Distintos tipos de necesidades de información 2. Herramientas
Más detallesSistemas de Información 12/13 La organización de datos e información
12/13 La organización de datos e información Departamento Informática e Ingeniería de Sistemas Universidad de Zaragoza (raqueltl@unizar.es) " Guión Introducción: Data Warehouses Características: entornos
Más detallesPROGRAMACIÓN. UNIDAD II. ALGORITMO PROFA : HAU MOY
PROGRAMACIÓN. UNIDAD II. ALGORITMO PROFA : HAU MOY ALGORITMO DEFINICIÓN: CONSISTE EN LA DESCRIPCIÓN CLARA Y DETALLADA DEL PROCEDIMIENTO A SEGUIR PARA ALCANZAR LA SOLUCIÓN A UN PROBLEMA EN DONDE SE ESTABLECE
Más detallesLos diagramas de clases y de objetos sirven para modelar diversos aspectos estructurales o estáticos de un sistema: Modelado - Vocabulario del Sistema
Modelado Los diagramas de clases y de objetos sirven para modelar diversos aspectos estructurales o estáticos de un sistema: Vocabulario del Sistema Distribución de Responsabilidades Semántica de una Clase
Más detallesPONTIFICIA UNIVERSIDAD CATOLICA DEL ECUADOR TEMA: AUTOR: DIRECTOR:
PONTIFICIA UNIVERSIDAD CATOLICA DEL ECUADOR FACULTAD DE INGENIERIA ESCUELA DE SISTEMAS TEMA: PRINCIPIOS Y TÉCNICAS PRÁCTICAS PARA LA IMPLEMENTACIÓN DE UN PROTOTIPO DE DATA WAREHOUSE EN SQL SERVER 2000
Más detallesCAPITULO 1 INTRODUCCION AL PROYECTO
CAPITULO 1 INTRODUCCION AL PROYECTO 1 INTRODUCCION AL PROYECTO 1.1 Marco Teórico Los procesadores digitales de señales ganaron popularidad en los años sesentas con la introducción de la tecnología de estado
Más detallesBASES DE DATOS TEMA 2 MODELOS DE DATOS
SES DE DTOS TEM 2 MODELOS DE DTOS Un modelo de datos es una serie de conceptos que puede utilizarse para describir un conjunto de datos y las operaciones para manipularlos. Hay dos tipos de modelos de
Más detallesEl diseño de la base de datos de un Data Warehouse. Marta Millan millan@eisc.univalle.edu.co www.eisc.univalle.edu.co/materias
El diseño de la base de datos de un Data Warehouse Marta Millan millan@eisc.univalle.edu.co www.eisc.univalle.edu.co/materias El modelo Multidimensional Principios básicos Marta Millan millan@eisc.univalle.edu.co
Más detallesDiseño Lógico de Data Warehouses a partir de Esquemas Conceptuales Multidimensionales
Instituto de Computación Facultad de Ingeniería Universidad de la República Pedeciba Informática Diseño Lógico de Data Warehouses a partir de Esquemas Conceptuales Multidimensionales Verónika Peralta Tesis
Más detallesContenido. 1. El proceso 2. Los modelos 3. Los diagramas 4. Ejemplo
Tutorial Contenido 1. El proceso 2. Los modelos 3. Los diagramas 4. Ejemplo 1. El proceso Fases soportadas por UML Análisis de requisitos de usuario Análisis de requisitos de software Diseño de la plataforma
Más detallesDiseño Organizacional
Diseño Organizacional DISEÑO ORGANIZACIONAL 1 Lectura No. 7 Nombre: Estructura y Diseño Organizacional Introducción En esta sesión presentaremos los conceptos que definen la estructura y el diseño organizacional.
Más detallesDED Diagramas de Estructura Lógica de Datos. Universidad de Oviedo Departamento de Informática
DED Diagramas de Estructura Lógica de Datos Universidad de Oviedo Departamento de Informática Contenidos Introducción Relaciones Construcción del modelo conceptual Normalización Primera Forma Normal Segunda
Más detallesBases de datos distribuidas Fernando Berzal, berzal@acm.org
Bases de datos distribuidas Fernando Berzal, berzal@acm.org Acceso a los datos Bases de datos relacionales: SQL O/R Mapping Bases de datos distribuidas Bases de datos NoSQL Bases de datos multidimensionales:
Más detallesDescripción del Curso
Curso Práctico de Modelado de Negocios BPMN con UML Descripción del Curso Durante este curso aprenderás de forma práctica el estándar BPMN (Business Process Management Notation) y las extensiones de UML
Más detallesCAPITULO 6. Análisis Dimensional y Semejanza Dinámica
CAPITULO 6. Análisis Dimensional y Semejanza Dinámica Debido a que son pocos los flujos reales que pueden ser resueltos con exactitud sólo mediante métodos analíticos, el desarrollo de la mecánica de fluidos
Más detalles1. Lenguaje de Definición de Datos. 2. Lenguaje de Manipulación de. Datos. M. C. Gustavo Alfonso Gutiérrez Carreón
1. Lenguaje de Definición de Datos 2. Lenguaje de Manipulación de Datos M. C. Gustavo Alfonso Gutiérrez Carreón Los 'sistemas de gestión de bases de datos (en inglés database management system, abreviado
Más detallesMódulo Minería de Datos
Módulo Minería de Datos Diplomado Por Elizabeth León Guzmán, Ph.D. Profesora Ingeniería de Sistemas Grupo de Investigación MIDAS Análsis Dimensional OLAP On-Line Analytical Processing Estructura del Proceso
Más detallesArquitectura de sistemas: Título: AnalyticsMOOC- Solución TIC Big Data para entornos MOOC Número de expediente: TSI
Arquitectura de sistemas: Título: AnalyticsMOOC- Solución TIC Big Data para entornos MOOC Número de expediente: TSI- 100105-2014-192 Código: Fecha: 11/12/2014 Persona de Contacto: Carlos Vicente Corral
Más detallesAlgoritmos. Medios de expresión de un algoritmo. Diagrama de flujo
Algoritmos En general, no hay una definición formal de algoritmo. Muchos autores los señalan como listas de instrucciones para resolver un problema abstracto, es decir, que un número finito de pasos convierten
Más detallesConcepción - Chile Marcela Varas Universidad de Concepción Chile - 2012
Presentación Concepción - Chile www.udec.cl Universidad de Concepción - Chile Estudiantes Universidad de Concepción Departamento de Ingeniería Informática y Ciencias de la Computación Facultad de Ingeniería
Más detallesProfesor(a): M. A. Zeferino Galarza Hernández
Área Académica: Informática IV Tema: Algoritmos Profesor(a): M. A. Zeferino Galarza Hernández Periodo: Enero-junio de 2012 IV Semestre. Asignatura: Informática IV Tema: Algoritmos Abstract Contains and
Más detallesSistemas de Data Warehousing
Federación Médica del Interior (FEMI) Sociedad Uruguaya de Informática en la Salud (SUIS) Información en Salud Edición 2009 Sistemas de Data Warehousing Dr. Ing. Adriana Marotta (In.Co - F.Ing - UDELAR)
Más detallesINTRODUCCION ANTECEDENTES:
INTRODUCCION ANTECEDENTES: En agosto de 1993, Codd y Date anunciaron un descubrimiento importante en el negocio de computadoras con 12 reglas para el proceso analítico en línea (OLAP). Desarrollado por
Más detallesAdministración de Proyectos de TI
Administración de Proyectos de TI VI Jornadas Universitarias de Sistemas de Información en Salud Lic. Gustavo Sobota Oficina de Proyectos Departamento de Informática en Salud Hospital Italiano de Buenos
Más detallesNombre de la asignatura: Algoritmos y Lenguajes de programación.
Nombre de la asignatura: Algoritmos y Lenguajes de programación. Créditos: 2-4- 6 Aportación al perfil Dominar la lógica necesaria para aprender lenguajes de programación de alto nivel para poder resolver
Más detallesUnidad III Modelamiento Multidimencional. Tecnología DATAWAREHOUSE
Unidad III Modelamiento Multidimencional Tecnología DATAWAREHOUSE Datawarehouse Colección de datos integrados, variantes en el tiempo, no volátiles, orientados a temas de interés para la gestión de una
Más detallesEl Sistema Gestor de Base de Datos (DBMS)
Pontificia Universidad Javeriana Contenido 1 Introducción 2 Evolución de los SGBD 3 Arquitectura del SGBD 4 Lenguajes de BD 5 Usuarios de la BD Introducción Se espera del SGBD (DBMS) que: 1 Permita a los
Más detallesCreación y utilización de localizadores y eventos
Creación y utilización de localizadores y eventos Clients SIG Dr. Joan Nunes Departament de Geografia / Miquel Àngel Vargas LIGIT localizaciones: principios 1/2 Representan la localización geográfica de
Más detallesBases de Datos. Diseño y Programación Avanzada de Aplicaciones. Curso
Bases de Datos Diseño y Programación Avanzada de Aplicaciones Curso 2002-2003 INDICE Fichero vs. Bases de Datos Relacionales Un fichero constituye la forma más básica de almacenamiento de información.
Más detallesConcepto de estado de resultados
Concepto de estado de resultados Es el estado financiero básico que muestra la utilidad o pérdida resultante en un periodo contable, a través del enfrentamiento entre los ingresos y los costos y gastos
Más detallesAfinación y Rendimiento de Bases de Datos
DIPLOMADO Afinación y Rendimiento de Bases de Datos TEMARIO DURACIÓN: 250 hrs. 1. Introducción a los Sistemas de Información y RDBMS (30 hrs.) 1. Sistemas de Información y RDBMS (30 hrs.) 1.1 Introducción
Más detallesSQL Server Business Intelligence parte 1
SQL Server Business Intelligence parte 1 Business Intelligence es una de las tecnologías de base de datos más llamativas de los últimos años y un campo donde Microsoft ha formado su camino a través de
Más detallesANEXO F ARQUITECTURAS DE INTELIGENCIA DE NEGOCIOS
ANEXO F ARQUITECTURAS DE INTELIGENCIA DE NEGOCIOS 1. Realizado por: Stephanie Herrera Bautista 2. Introducción: 2.1. Propósito: Se busca realizar el planteamiento de las diversas arquitecturas que se pueden
Más detallesEl Proceso. Capítulo 2 Roger Pressman, 5 a Edición. El Proceso de Desarrollo de Software
El Proceso Capítulo 2 Roger Pressman, 5 a Edición El Proceso de Desarrollo de Software Qué es? Marco de trabajo de tareas a realizar para desarrollar Software de alta calidad. Es sinónimo de Ingeniería
Más detallesM465: Tanque de Agua. A) Presentación del problema
M465: Tanque de Agua A) Presentación del problema El diagrama muestra la forma y dimensiones de un tanque de almacenamiento de agua. Al inicio el tanque está vacío. Una llave está llenando el tanque a
Más detallesInterfaces. Carrera: SCF Participantes. Representantes de la academia de sistemas y computación de los Institutos Tecnológicos.
1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Clave de la asignatura: Horas teoría-horas práctica-créditos Interfaces Ingeniería en Sistemas Computacionales SCF - 0417 2-4-8 2.- HISTORIA
Más detallesPrincipios de Análisis Informático. Tema 3: Fase de inicio
Principios de Análisis Informático Tema 3: Fase de inicio Eduardo Mosqueira Rey LIDIA Laboratorio de Investigación y desarrollo en Inteligencia Artificial Departamento de Computación Universidade da Coruña,
Más detallesCreación y Mantenimiento de Componentes Software en Sistemas de Planificación de Recursos Empresariales y de Gestión de...
Creación y Mantenimiento de Componentes Software en Sistemas de Planificación de Recursos Empresariales y de Gestión de... Certificados de profesionalidad Ficha Técnica Categoría Informática y Programación
Más detallesLicencia GNU FDL. Detalle del cambio. Ing. Bernabeu Ricardo Dario, Ing. García Mattío Mariano Alberto. Versión incial. 05/11/2009
Licencia GNU FDL Copyright 2009 Ing. Bernabeu Ricardo Dario, Ing. García Mattío Mariano Alberto. Se otorga permiso para copiar, distribuir y/o modificar este documento bajo los términos de la Licencia
Más detallesINFORMÁTICA Y COMUNICACIONES
441 INFORMÁTICA Y COMUNICACIONES Microsoft Access 2003 (Completo) DESCRIPCIÓN Microsoft Access 2003 (Completo) Descripción del funcionamiento del programa de gestión de bases de datos Microsoft Access
Más detallesUNDÉCIMA CONFERENCIA DE NAVEGACIÓN AÉREA. Montreal, 22 de septiembre - 3 de octubre de 2003
AN-Conf/11-WP/21 22/5/03 UNDÉCIMA CONFERENCIA DE NAVEGACIÓN AÉREA Montreal, 22 de septiembre - 3 de octubre de 2003 Cuestión 1 del orden del día: Introducción y evaluación de un concepto operacional global
Más detallesSistemas Electrónicos Digitales
Sistemas Electrónicos Digitales Profesor: Carlos Herrera C. I. Unidad COMPUERTAS LOGICAS Las compuertas lógicas son dispositivos que operan con aquellos estados lógicos Binarios y que funcionan igual que
Más detallesTÉCNICO SUPERIOR UNIVERSITARIO EN MECATRÓNICA ÁREA AUTOMATIZACIÓN EN COMPETENCIAS PROFESIONALES ASIGNATURA DE LENGUAJE DE PROGRAMACIÓN
TÉCNICO SUPERIOR UNIVERSITARIO EN MECATRÓNICA ÁREA AUTOMATIZACIÓN EN COMPETENCIAS PROFESIONALES ASIGNATURA DE LENGUAJE DE PROGRAMACIÓN 1. Competencias Implementar sistemas de medición y control bajo los
Más detallesJava Avanzado. Guía 1. Java Avanzado Facultad de Ingeniería. Escuela de computación.
Java Avanzado. Guía 1 Java Avanzado Facultad de Ingeniería. Escuela de computación. Java Avanzado. Guía 2 Introducción Este manual ha sido elaborado para orientar al estudiante de Java Avanzado en el desarrollo
Más detallesBases de Datos Masivas
Bases de Datos Masivas Data Warehouse Bases de Datos Multidimensionales Banchero, Santiago Septiembre 2015 Concepto de DW. Definición según W. H. Inmon: A data warehouse is a subject-oriented, integrated,
Más detallesFacultad de Ciencias Económicas. Departamento de Sistemas. Asignatura: INTELIGENCIA DE NEGOCIOS. Plan 1997
UNIVERSIDAD DE BUENOS AIRES Facultad de Ciencias Económicas Departamento de Sistemas Asignatura: INTELIGENCIA DE NEGOCIOS Código: 715 Plan 1997 Cátedra: DEPARTAMENTO DE SISTEMAS Carrera: Licenciado en
Más detallesMODELOS DE PROCESO EVOLUTICO
MODELOS DE PROCESO EVOLUTICO ALUMNOS: RAUL MEXICANO HERNANDEZ KARIM PEREZ CONDE 4 SEMESTRE GRUPO: E PROCESO DE SOFTWARE El modelo Evolutivo Existe una gran variedad de procesos de software pero hablaremos
Más detalles3. TÉCNICAS DE DISEÑO
3. TÉCNICAS DE DISEÑO 3.1 Top Down También conocida como de arriba-abajo y consiste en establecer una serie de niveles de mayor a menor complejidad (arriba-abajo) que den solución al problema. Consiste
Más detallesDefinimos un Sistema Gestor de Bases de Datos o SGBD, también llamado DBMS (Data Base Management System) como una colección de datos relacionados entr
Introducción Arquitectura de los DBMS Lenguajes de los DBMS Diccionario de datos Seguridad e integridad de los datos Administrador del DBMS Arquitectura Cliente-Servidor Definimos un Sistema Gestor de
Más detallesCapítulo 16. Diagrama de Clases UML
Capítulo 16. Diagrama de Clases UML Florentino TORRES M. CINVESTAV-Tamaulipas 15 de Oct del 2012 Florentino TORRES M. (CINVESTAV) 15 de Oct del 2012 1 / 70 1 Capítulo 16. Diagrama de Clases UML Aplicando
Más detallesA continuación se presenta la información de la altura promedio para el año de 1998 en Holanda de hombres y mujeres jóvenes.
M150: Creciendo A) Presentación del problema LOS JOVENES CRECEN MAS ALTO A continuación se presenta la altura promedio para el año de 1998 en Holanda de hombres y mujeres jóvenes. B) Preguntas del problema
Más detallesTema 2 Introducción a la Programación en C.
Tema 2 Introducción a la Programación en C. Contenidos 1. Conceptos Básicos 1.1 Definiciones. 1.2 El Proceso de Desarrollo de Software. 2. Lenguajes de Programación. 2.1 Definición y Tipos de Lenguajes
Más detallesIngeniería de Requerimientos. requiere de un Sistema de Software.
Ingeniería de uestableciendo lo que el cliente requiere de un Sistema de Software. Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 1 Objetivos u Introducción a la Noción
Más detallesINTERPRETACIÓN NORMA OHSAS 18001:2007 MÓDULO 1 SESIÓN 1 INTERPRETACIÓN DE LA NORMA OHSAS 18001:2007 DOCENTE: Ing. Dª. Ana I.
INTERPRETACIÓN NORMA OHSAS 18001:2007 MÓDULO 1 SESIÓN 1 INTERPRETACIÓN DE LA NORMA OHSAS 18001:2007 DOCENTE: Ing. Dª. Ana I. Menac Lumbreras Especializados 1 TEMA 1 Contenidos INTRODUCCIÓN A LA NORMA OHSAS
Más detallesAtributos Los atributos son las columnas de un relación y describen características particulares de ella.
Unidad III: Modelo relacional 3.1 Estructura básica Tablas El modelo relacional proporciona una manera simple de representar los datos: una tabla bidimensional llamada relación. título año duración tipo
Más detallesPOLITICAS NACIONALES BASADAS EN EVIDENCIA: SIGNIFICADO E IMPLICACIONES
COMISION INTERAMERICANA PARA EL CONTROL DEL ABUSO DE DROGAS C I C A D Secretaría de Seguridad Multidimensional QUINCUAGÉSIMO PRIMER PERÍODO ORDINARIO DE SESIONES Del 9 al 11 de mayo de 2012 Washington,
Más detallesMOLAP REALIZADO POR: JOSE E. TABOADA RENNA
MOLAP REALIZADO POR: JOSE E. TABOADA RENNA BASE DE DATOS Conjunto de datos estructurados, fiables y homogéneos organizados independientemente en máquina, m accesibles en tiempo real, compatible por usuarios
Más detallesAPOYO PARA LA TOMA DE DECISIONES
APOYO PARA LA TOMA DE DECISIONES Cátedra: Gestión de Datos Profesor: Santiago Pérez Año: 2006 Bibliografía: Introducción a las Bases de Datos. DATE - 1 - 1. INTRODUCCION APOYO PARA LA TOMA DE DECISIONES
Más detallesIng. Yim Isaias Apestegui Florentino
Definicion de Modelo Relacional El Modelo Relacional Se basa en una representación del mundo real en que los datos se describen como entidades, relaciones y atributos. El principal concepto del modelo
Más detalles1. Almacenamiento redundante
ALTA DISPONIBILIDAD Los sistemas RAID los hacemos con un conjunto de discos. Por un lado hay RAID que valen para: *VELOCIDAD. Optimizan el rendimiento para conseguir velocidad. *SEGURIDAD. Si falla un
Más detallesa la definición de un método aplicable a problemas de visualización de archivos incompletos o de formato desconocido.
1. INTRODUCCIÓN En el presente documento se expone un método que facilita la visualización de todo tipo de archivos, completos o incompletos, partiendo de la identificación del formato de los mismos. Los
Más detallesDiseño de Bases de Datos (TEMAS 1 Y 2)
Departamento de Lenguajes y Sistemas Informáticos Avda Reina Mercedes s/n. 41012 Sevilla Tlf/Fax 954 557 139 E-mail lsi@lsi.us.es www.lsi.us.es E.T.S. Ingeniería Informática Diseño de Bases de Datos (TEMAS
Más detallesModelado Básico con Casos de Uso. Diseño de Software Avanzado Departamento de Informática
Modelado Básico con Casos de Uso El Modelo de Casos de Uso La técnica de los casos de uso (inventada por Ivar Jacobson): Objetivo: identificar la funcionalidad de un sistema (requisitos funcionales). Método:
Más detallesDeveloping ASP.NET MVC 4 Web Applications
Código: S28 Duración: 25 horas En este curso, los estudiantes aprenderán a desarrollar aplicaciones ASP.NET MVC con avanzadas tecnologías y herramientas de.net Framework 4.5. Se centrará en la codificación
Más detallesMODELOS Razones: Contribuyen a formular una teoría orientada a comprender el comportamiento del consumidor. Facilitan el aprendizaje de lo que se cono
Modelos Un modelo es una representación, física o abstracta, de todos o algunos aspectos de la realidad. Un modelo debe ayudar a describir, predecir o resolver el fenómeno que trata de representar. MODELOS
Más detallesOBJETIVO GENERAL: Al terminar el curso el alumno será capaz de analizar, diseñar e implementar bases de datos distribuidas
PLAN DE ESTUDIOS 2008 LICENCIADO EN INFORMÁTICA FACULTAD DE CONTADURÍA, ADMINISTRACIÓN E INFORMÁTICA ASIGNATURA: BASE DE DATOS III ÁREA DEL CONOCIMIENTO: TRATAMIENTO DE LA INFORMACIÓN CLAVE: I6BD3 ETAPA
Más detallesMICROSOFT ACCESS 2016 Básico
MICROSOFT ACCESS 2016 Básico METODOLOGÍA DE LOS CURSOS Cursos interactivos sobre materias especializadas en los que el alumno avanza de forma guiada bajo una concepción learning by doing (aprender haciendo).
Más detalles