Breve Introducción a las Bodegas de Datos Dr. José Torres Jiménez Octubre 2011

ii

Índice general 1. Introducción a los Sistemas Para Apoyar la Toma de Decisiones 1.1. DSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1. Beneficios y Limitaciones de un DSS . . . . . . . . . . . . 1.2. Historia de los DSS . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3. Componentes de un DSS . . . . . . . . . . . . . . . . . . . . . . . 1.4. Categorías y Clases de los DSS . . . . . . . . . . . . . . . . . . . 1.5. Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1 2 3 3 4 4

2. Introducción A las Bodegas de Datos

5

2.1. Modelado Dimensional . . . . . . . . . . 2.2. Diferencias entre OLTP y DDW . . . . 2.2.1. Velocidad de Respuesta . . . . . 2.2.2. Nivel Jerárquico de los Usuarios 2.2.3. Modelado . . . . . . . . . . . . . 2.2.4. Almacenamiento Requerido . . . 2.2.5. Horizonte Temporal . . . . . . . 2.2.6. Una Computadora o Dos . . . . 2.2.7. Extracción de Información . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

5 7 7 7 8 8 8 8 8

3. Diseño Dimensional 3.1. Ejemplo de una Cadena de Tiendas de Comodidad 3.1.1. Dimensión Tiempo . . . . . . . . . . . . . . 3.1.2. Dimensión Producto . . . . . . . . . . . . . 3.1.3. Dimensión Tienda . . . . . . . . . . . . . . 3.1.4. Dimensión Promoción . . . . . . . . . . . . 3.1.5. Modelo Dimensional Completo . . . . . . . 3.1.6. Ejemplos de consultas . . . . . . . . . . . . 3.2. Ejemplo de bodegas de productos . . . . . . . . . . 3.2.1. Ejemplos de consultas . . . . . . . . . . . . 3.3. Tablas de hechos y tablas de dimensiones . . . . . 3.3.1. Hechos . . . . . . . . . . . . . . . . . . . . . 3.3.2. Atributos . . . . . . . . . . . . . . . . . . . 3.3.3. Dimensiones . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

9 9 11 11 11 11 11 11 17 17 20 20 20 20

iii

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

iv

ÍNDICE GENERAL 3.4. 3.5. 3.6. 3.7. 3.8. 3.9.

Drilling Up and Drilling Down Dimensiones Cambiantes . . . . Dimensiones degeneradas . . . Aditividad . . . . . . . . . . . . Tablas de hechos sin hechos . . Dimensiones N_a_N . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

20 22 22 22 23 24

4. Integración de Esquemas 4.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2. Semántica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3. Propósito de la Integración de Esquemas . . . . . . . . . . . 4.4. Proximidad Semántica . . . . . . . . . . . . . . . . . . . . . 4.4.1. Contexto . . . . . . . . . . . . . . . . . . . . . . . . 4.4.2. Abstracción . . . . . . . . . . . . . . . . . . . . . . . 4.4.3. Dominios . . . . . . . . . . . . . . . . . . . . . . . . 4.4.4. Estados . . . . . . . . . . . . . . . . . . . . . . . . . 4.5. Equivalencia Semántica . . . . . . . . . . . . . . . . . . . . 4.6. Relación Semántica . . . . . . . . . . . . . . . . . . . . . . . 4.7. Relevancia Semántica . . . . . . . . . . . . . . . . . . . . . 4.8. Parecido Semántico . . . . . . . . . . . . . . . . . . . . . . . 4.9. Incompatibilidad Semántica . . . . . . . . . . . . . . . . . . 4.10. Incompatibilidad de Dominios . . . . . . . . . . . . . . . . . 4.10.1. Conflictos de Nombres . . . . . . . . . . . . . . . . . 4.10.2. Conflictos de Representación de Datos . . . . . . . 4.10.3. Conflictos de Escala de Datos . . . . . . . . . . . . . 4.10.4. Conflictos de Precisión de Datos . . . . . . . . . . . 4.10.5. Conflictos de Valor por Omisión . . . . . . . . . . . 4.10.6. Conflictos de Restricciones de Integridad . . . . . . . 4.11. Incompatibilidad de Definición de Entidades . . . . . . . . . 4.11.1. Conflictos de Identificador de Bases de Datos . . . . 4.11.2. Conflictos de Nombres . . . . . . . . . . . . . . . . . 4.11.3. Conflictos de Compatibilidad a la Unión . . . . . . . 4.11.4. Conflictos de Isomorfismos de Esquemas . . . . . . . 4.11.5. Conflictos de Datos Faltantes . . . . . . . . . . . . . 4.12. Inconsistencia . . . . . . . . . . . . . . . . . . . . . . . . . . 4.13. Incompatibilidad por Nivel de Abstracción entre Entidades 4.14. Problema de Discrepancia Esquemática . . . . . . . . . . . 4.14.1. Conflicto Valor Dato-Atributo . . . . . . . . . . . . . 4.14.2. Conflicto Atributo-Entidad . . . . . . . . . . . . . . 4.14.3. Conflicto Valor Dato - Entidad . . . . . . . . . . . . 4.15. Tarea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27 27 27 27 28 28 29 29 29 30 30 30 30 31 31 31 31 33 33 33 33 33 33 34 34 34 35 35 35 36 36 36 37 37

ÍNDICE GENERAL

v

5. Tablas Temporales 5.1. Tipos de Datos para Manejo de Tiempo . . . . 5.2. Funciones Para Manejo de Tiempo en Oracle . 5.2.1. Inicialización de una Tabla Temporal . . 5.2.2. Manipulación de una Tabla Temporal . 5.3. Instante . . . . . . . . . . . . . . . . . . . . . . 5.4. Intervalo . . . . . . . . . . . . . . . . . . . . . . 5.5. Eventos que comparten una fracción de tiempo 5.6. Tarea . . . . . . . . . . . . . . . . . . . . . . . 5.7. Manejo de Intervalos en Oracle . . . . . . . . . 5.8. Períodos . . . . . . . . . . . . . . . . . . . . . . 5.9. Tarea . . . . . . . . . . . . . . . . . . . . . . . 5.10. Tablas de Estado . . . . . . . . . . . . . . . . . 5.11. Tarea . . . . . . . . . . . . . . . . . . . . . . . 5.12. Tarea . . . . . . . . . . . . . . . . . . . . . . . 6. Visualización de Información 6.1. Introducción . . . . . . . . . . . . . . 6.2. Cognición Externa . . . . . . . . . . 6.3. Visualización de Información . . . . 6.4. Amplificación Cognoscitiva . . . . . 6.5. Mapeo de Datos a una Forma Visual 6.5.1. Tablas de Datos . . . . . . . 6.5.2. Estructuras Visuales . . . . . 6.5.3. Transformaciones de Vistas . 6.5.4. Interacción Humana . . . . . 6.6. Objetivo Final de la Visualización de

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

39 39 39 40 41 44 44 45 45 45 45 48 49 50 51

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Información .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

53 53 54 55 56 57 57 59 62 63 63

. . . . . . . . . . . . . .

vi

ÍNDICE GENERAL

Capítulo 1

Introducción a los Sistemas Para Apoyar la Toma de Decisiones En este capítulo se describirán los aspectos fundamentales que están involucrados en el proceso de toma de decisiones.

1.1.

DSS

Los sistemas para apoyar la toma de decisiones (también conocidos por sus siglas en inglés como DSS) son en esencia muy diversos, pero comparten algunas características en comun que son listadas a continuación: 1. Se emplean en contextos de decisión no estructurados o semiestructurados. Un contexto estructurado es aquel que tiene objetivo no conflictivos, claramente definido, con pocas alternativas de decisión y normalmente son conocidos los efectos de las decisiones. 2. Tratan de apoyar al tomador de decisiones más que reemplazarlo. 3. Soportan todas las fases del proceso de toma de decisiones. 4. Se enfocan en la efectividad del proceso de toma de decisiones, más que en su eficiencia. 5. Usan datos y modelos predefinidos. 6. Son interactivos y en general amigables. 7. Se desarrollan a través de un proceso iterativo y evolutivo. 1

2CAPÍTULO 1. INTRODUCCIÓN A LOS SISTEMAS PARA APOYAR LA TOMA DE DECISIONES 8. Soportan los niveles estratégicos y tácticos de las empresas. 9. Soportan la toma de decisiones independientes o interdependientes. 10. Soportan contextos de toma de decisiones individuales, grupales y en equipo.

1.1.1.

Beneficios y Limitaciones de un DSS

Los beneficios que puede aportar un DSS son: 1. Extienden la capacidad del tomador de decisiones para procesar información y conocimiento. 2. Permiten el atacar problemas complejos, de gran escala y que normalmente demandarían muchisimo tiempos sin el uso del DSS. 3. Permiten reducir el tiempo necesario para llegar a una decisión. 4. Aunque es dificil de evaluar pero normalmente incrementan la confiabilidad de los resultados que se logran al tomar una decisión. 5. Motivan la exploración y el descubrimiento del tomador de decisiones. 6. Dan nuevas evidencias para apoyar una decisión o apoyan las suposiciones previas. 7. Crean una ventaja competitiva en las empresas. Las limitaciones que tiene un DSS son: 1. Normalmente no involucran aspectos de la inteligencia humana como la creatividad, la imaginación y la intuición. 2. El DSS tiene como limitantes: el equipo computacional en el que corre, el diseño del mismo, y el conocimiento que posee cuando es usado. 3. Las interfaces no son suficientemente sofisticadas como para soportar la generación de voz, el reconocimiento de voz y el manejo de lenguaje natural. 4. Son aplicables a contextos especificos.

1.2. HISTORIA DE LOS DSS

1.2.

3

Historia de los DSS

Nacen del interés de aplicar métodos cuantitativos al proceso de toma de decisiones. Hay dos artículos a los que se les asocia el uso del y acuñamiento del concepto de DSS : 1. ”Models and Managers: The Concept of a Decision Calculus”, Little, J.D. (1970). La idea planteada en este artículo es el contar con un sistema adaptable a las necesidades del usuario, fácil de usar, simple y robusto para auxiliar al procesamiento de datos para apoyar a los administradores en el proceso de toma de decisiones. 2. ”A Framework for Management Information Systems”, Gorry and Scott Morton (1989). En este artículo se desarrolla un modelo bidimensional para soportar computacionalmente a las actividades administrativas. Este modelo usa el tipo de decisión como la dimensión vertical , el tipo de decisión puede ser estructurada, semiestructurada o no-estructurada dependiendo del grado de programación con el que se cuente. En la dimensión horizontal se indica el nivel actividad administrativa que se requiere, en esencia se tienen los niveles estrátegico, táctico (control de la administración) y operacional.

1.3.

Componentes de un DSS

Los componentes de un DSS son: 1. El Sistema de Administración de Datos. Compuesto en esencia por la base de datos y una facilidad para realizar consultas. 2. El Sistema de Administración de Modelos. Responsable de controlar el almacenamiento y recuperación de los datos relacionados con los modelos cuantitativos en base a los cuales se estructura el proceso de análisis de decisiones. 3. La Máquina de Conocimiento. Permite el derivar nuevo conocimiento en base a los datos o a conocimiento previamente derivado. La máquina de conocimiento maneja: a) estrategias de solución específicas de acuerdo al contexto, reglas derivadas, restricciones inherentes a una situación particular, probabilidades a priori. Básicamente podemos ubicar que el conocimiento contenido en un DSS pueden ser HECHOS e HIPOTESIS (reglas o relaciones que se cree existen entre los hechos). La máquina de conocimiento tiene dos funciones básicas: a) La Adquisición del Conocimiento; y b) La Recuperación del Conocimiento (Máquina de Inferencias). 4. La Interface con el Usuario.Esta interface debería ser ad-hoc al usuario. Se pretende que está interfaz tenga capacidades de generación de voz, reconocimiento de voz, manejo de lenguaje natural, presentación de los

4CAPÍTULO 1. INTRODUCCIÓN A LOS SISTEMAS PARA APOYAR LA TOMA DE DECISIONES datos, conocimiento, opciones y en general de toda la información de una manera adecuada al usuario (ejemplo de KEIM), se busca de manera adicional agregar afectividad a la interfaz y el uso de agentes inteligentes. 5. El Usuario del DSS. Podemos ubicar que existen diversos tipos de usuarios de un DSS, pero en esencia podemos distinguir: a) El Administrador del DSS; b) El Mantenedor de los Datos, Base de Conocimiento, Reglas, etc.; y c) El Tomador de Decisiones.

1.4.

Categorías y Clases de los DSS

Centrados en los Datos y Centrados en los Modelos Los centrados en los datos se enfocan en la recuperación y análisis de los datos. Los centrados en los modelos incluyen manejo de simulación, optimizadores, manejo de escenarios. DSS Formales y Ad-Hoc Los formales se enfocan al manejo de decisiones periódicas, recurrentes, y estructuradas. Los ad-hoc se enfocan a situaciones más restringidas y normalmente involucran decisiones no periódicas. DSS Dirigido y No Dirigido Esta clasificación se refiere al grado de dependencia del DSS con respecto al usuario, i.e. que tan automático es el proceso del DSS. SistemasProceduralesyNo − Procedurales Esto se refiere a si se debe especificar el Qué y el Cómo o sólo el Qué. Sistemas de Hipertexto Sistemas de Hojas de Cálculo Sistemas Grupales o Individuales Sistemas Expertos

1.5.

Conclusión

Un DSS es un sistema dinámico que requiere conocimiento más alla de lo que brinda un sistema de información tradicional. Demanda el uso de una base de conocimiento para que el tomador de decisiones esté mejor informado y se le apoye en el procesamiento de información y el análisis de alternativas de solución.

Capítulo 2

Introducción A las Bodegas de Datos En este capítulo introduciremos los conceptos asociados a bodegas de datos (Data Warehouses) y bases de datos relacionales. En primer lugar presentaremos el modelado dimensional y el modelado relacional, en segundo termino destacaremos las diferencias más importantes entre un sistema de bodega de datos y un sistema de bases de datos relacionales, en tercer termino presentaremos un breve resumen del lenguaje de consultas más usado para extracción de información de una base de datos: SQL. A manera de una pequeña definición podemos decir que: una Bodega de Datos es un recurso integrado de datos que está basado en un modelo de datos que permita aglutinar información histórica proveniente de sistemas de procesamiento de transacciones en línea (OLTP) y cuyo objetivo es proporcionar información pertinente para el proceso de toma de decisiones en las empresas.

2.1.

Modelado Dimensional

El modelado dimensional es un nuevo nombre para una vieja técnica que permite que los datos almacenados en un sistema computacional sean presentados de una manera ad-hoc para sustentar el proceso de toma de decisiones dentro de las empresas. El modelado dimensional está sustentado en la presentación de los datos usando un paradigma de cubos e hipercubos, y se soportan que se extraigan ”rebanadas”(slicing) y ”cubitos”(dicing) de estos cubos/hipercubos. El caso más simple de un cubo es un solo punto, en el cuál solo tenemos un dato (posiblemente resultado de realizar operaciones de agrupación); el siguiente caso es cuando el cubo está representado por una línea, la cuál contiene una secuencia de datos (posiblemente del resultado de procesar previamente datos); el siguiente nivel está representado por un plano, en el cuál tenemos el equivalente a una matriz, el ejemplo más conocido es el caso de una tabla cruzada, esto 5

6

CAPÍTULO 2. INTRODUCCIÓN A LAS BODEGAS DE DATOS

S1 S2 S3 S4 S5

P1 0 20 10 10 0 40

P2 10 10 0 0 10 30

P3 20 0 10 0 30 60

P4 0 10 0 20 0 30

30 40 20 30 40

Cuadro 2.1: Tabla Cruzada de Proveedores y Partes

puede ser visto en la tabla 2.1 dónde tenemos la relación entre proveedores y partes, y es fácil poder derivar información relacionada con los totales de partes proveidas; el siguiente nivel es cuando el hipercubo está representado por tres dimensiones y típicamente una de estas dimensiones es la dimensión temporal; y así sucesivamente subiendo a cuatro, cinco, seis, ... , dimensiones. Como puede notarse de lo expuesto, el modelado dimensional permite que los datos sean visualizados/procesados de una manera que facilite su análisis y el proceso de toma de decisiones. Otra característica fundamental del modelado dimensional es que casi siempre una de las dimensiones es el tiempo, de manera tal que los hipercubos contienen información histórica que permite tener un horizonte de análisis mas alla de lo que permite un sistema tradicional donde típicamente solo se tiene accesible solo un período fiscal o natural. Un ejemplo clásico del modelado dimensional es aquel donde tenemos una dimensión geográfica que indica la ubicación de un conjunto de tiendas; una dimensión de productos que se refiere al conjunto de items que se venden en las tiendas; una dimensión temporal que ubica calendáricamente ventas de productos en las tiendas; y deseamos visualizar la cantidad de dinero que es recolectado por la venta de productos en las tiendas en la dimensión temporal (i.e. los hechos), esto puede verse en la figura 2.1. Adicionalmente considere que cada una de las tres dimensiones puede ser agrupada de acuerdo a 10 criterios (ejemplo: tiempo=hora, día, semana, quincena, mes,.....; geográfica=calle, colonia, municipio, estado, país,....; producto=item, subfamilia, familia,...) entonces el número de posibles maneras de visualizar los datos de acuerdo a las agrupaciones será: 10 × 10 × 10=1000. En un sistema tradicional requeriríamos de la creación de los programas que permitieran generar las diferentes manera de ver los datos, más en un sistema que soporte el modelado dimensional se maneja el concepto de reportes ”bajo demanda”, es decir el usuario dinámicamente decide como quiere ver los datos y el sistema construye dicho reporte. En contraposición con el modelado multidimensional de una bodega de datos, donde el objetivo último es presentar los datos para facilitar su análisis y el proceso de toma de decisiones, en el modelado de bases de datos relacionales se busca el tener un modelo con el mínimo de redundancia para economizar el espacio ocupado por los datos y de ser posible eficientar el acceso.

2.2. DIFERENCIAS ENTRE OLTP Y DDW

7

Figura 2.1: Ejemplo de un modelo multidimensional de productos, tiempo y ubicación geográfica.

2.2.

Diferencias entre OLTP y DDW

Los sistemas tradicionales de procesamiento de información son conocidos como sistemas de procesamiento de transacciones en línea (OLTP) en ellos lo más importante es el registro y manipulación eficientes de las diferentes operaciones que suceden dentro de una empresa. Los sistemas de bodegas de datos dimensional (DDW) normalmente no están en línea y el enfásis está en el poder extraer información relevante de los datos provenientes de los sistemas OLTP. Enseguida presentaremos las diferencias esenciales que existen entre estos dos tipos de sistemas.

2.2.1.

Velocidad de Respuesta

Se espera que un sistema OLTP responda en fracciones de segundo (v.g. el sistema SABRE es capaz de procesar del orden de 13,000 transacciones por segundo). Un sistema DDW tiene tiempos de respuesta tan grandes como decenas de horas.

2.2.2.

Nivel Jerárquico de los Usuarios

Un sistema OLTP está orientado sobre todo al nivel operacional y al nivel táctico, en contraposición el sistema DDW está orientado a los niveles táctico y estratégico.

8

2.2.3.

CAPÍTULO 2. INTRODUCCIÓN A LAS BODEGAS DE DATOS

Modelado

En OLTP se usa como técnica primordial el modelo Entidad Relación, en el DDW el modelado multidimensional. Como ya se comentó cada una de estas técnicas persiguen objetivos diferentes. En el DDW el modelo resultante es tipicamente un star-join donde se tienen múltiples tablas de dimensiones y una tabla de hechos, en OLTP el modelo resultante es mucho más complejo y normalmente involucra más tablas.

2.2.4.

Almacenamiento Requerido

Los sistemas OLTP no demandan demasiado espacio de almacenamiento, mientras que los DDW si. Existe una diferencia que es típicamente de tres ordenes de magnitud (OLTP=Giga, DDW=Tera)

2.2.5.

Horizonte Temporal

Los sistemas OLTP normalmente mantienen información en línea de un año, los DDW pueden mantener disponible información de varios años (claro esto varía de aplicación en aplicación, v.g. una compañía telefónica mantiene sólo unos pocos meses en línea).

2.2.6.

Una Computadora o Dos

Existe un dilema si el DDW debe ser soportado en el mismo hardware que el OLTP. Los que opinan que deben ser dos se basan en una cuestión de DESEMPEÑO, los otros se basan en una cuestión ECONÓMICA.

2.2.7.

Extracción de Información

En OLTP se usa normalmente SQL, en DDW se usa SQL + Herramientas que soportan OLAP (MOLAP ó ROLAP). OLAP=On Line Analytic Processing. MOLAP=Multidimensional OLAP(Dos modelos de datos diferentes). ROLAP=Relational OLAP (el modelo de datos relacional para las dos aplicaciones).

Capítulo 3

Diseño Dimensional En este capítulo presentaremos algunos ejemplos de diseño dimensional asi como los conceptos teóricos más relevantes del modelado dimensional. Para empezar podemos comentar que el proceso de diseño dimensional de una bodega de datos está compuesto de cuatro pasos: 1. Selección del proceso de negocio a modelar. 2. Determinar la granularidad del proceso de negocio. 3. Selección de las dimensiones del proceso. 4. Seleccionar los hechos que poblarán la bodega de datos.

3.1.

Ejemplo de una Cadena de Tiendas de Comodidad

La cadena de tiendas tiene 500 tiendas repartias en un área que abarca tres estados. Cada tienda tiene diversos departamentos: 1. Abarrotes 2. Comidas Congeladas 3. Carnicería 4. Licores 5. Florería 6. Farmacía. 9

10

CAPÍTULO 3. DISEÑO DIMENSIONAL

Figura 3.1: Modelado dimensional inicial para la cadena de tiendas

Los items individuales son llamados SKUs (Stock Keeping Units). Cerca de 40,000 productos son manufacturados por externos y tienen su propio código de barras de acuerdo al UPC (Universal Product Codes). Cerca de 20,000 artículos son manejados internamente y se les pega una etiqueta con un código de barras propio (solo reconocido en las tiendas) para facilitar su registro. Bajo este panorama uno de los procesos que es importante modelar es el proceso de venta de mercancias, asumamos que el nivel de granularidad es el movimiento de un producto individual por día en cada tienda. (No se decidio registrar la venta individual por motivo del volumen de datos, esto por ejemplo no permitirá realizar un análisis de la canasta de mercado). Respecto a las dimensiones que se desea incluir en el modelo tenemos que la dimensión tiempo es necesaria, la dimensión tienda también y la dimensión producto de la misma manera es necesaria, adicionalmente asumamos que se desea llevar el control de las promociones bajo las cuales se venden los productos. El modelo dimensional tentativo es ilustrado en la figura 3.1

3.1. EJEMPLO DE UNA CADENA DE TIENDAS DE COMODIDAD

3.1.1.

11

Dimensión Tiempo

Viendo en mayor detalle la dimensión tiempo, es necesario que especifiquemos los diversos atributos que definirán los niveles de agregación, agrupación de esta dimensión. Se define que es necesario saber: el día de la semana, el día del mes, el día en el año, el número de semana, el mes, el trimestre, el año, y la estación. Esto se ilustra en la figura 3.2

3.1.2.

Dimensión Producto

La dimensión producto permite el que se puedan obtener reportes a diferente nivel de detalle respecto a la venta de productos. Tenemos por ejemplo el nivel de producto individual (de acuerdo al SKU), a la marca , subcategoría, categoría, y departamento (aunque existen muchos más atributos). Esto puede verse en el modelo dimensional actualizado en la figura 3.3

3.1.3.

Dimensión Tienda

Esta dimensión permite la ubicación geográfica de cada una de las tiendas, se tiene identificado que es importante llevar el control de la ubicación a nivel de: Calle, Colonia, Municipio y Estado. El modelo dimensional incorporando las dimensiones de tiempo, producto y tienda es visto en la figura 3.4

3.1.4.

Dimensión Promoción

La dimensión promoción permite llevar el control de la eficacia de las promociones. Se registra la promoción bajo la cual es vendido cada producto. Los atributos de interés de esta dimensión son: Nombre de la promoción, Inicio de la promoción, Fin de la promoción y Costo de la promoción. El modelo dimensional completo está ilustado en la figura 3.5

3.1.5.

Modelo Dimensional Completo

El modelo dimensional completo incluyendo iconos identificadores de la tabla de hechos y de dimensiones esta ilustrado en la figura 3.6

3.1.6.

Ejemplos de consultas

1. Obtener total de ventas en pesos de los productos con subcategoría=”Servilletas de Papel”, en el municipio de Cuernavaca, durante la estación de Verano de 1998 y que hayan sido vendidas con la promoción ”Todo al 2x1”. 2. Obtener el total de tickets involucrados en ventas y agrupados por día de la semana.

12

CAPÍTULO 3. DISEÑO DIMENSIONAL

Figura 3.2: Modelo Dimensional de la Cadena de Tiendas Agregando Atributos de Tiempo

3.1. EJEMPLO DE UNA CADENA DE TIENDAS DE COMODIDAD

13

Figura 3.3: Modelo Dimensional con atributos de tiempo y producto definidos.

14

CAPÍTULO 3. DISEÑO DIMENSIONAL

Figura 3.4: Modelo dimensional incluyendo las dimensiones de tiempo, producto y tienda.

3.1. EJEMPLO DE UNA CADENA DE TIENDAS DE COMODIDAD

15

Figura 3.5: Modelo dimensional de la cadena de tiendas con todas las dimensiones definidas

16

CAPÍTULO 3. DISEÑO DIMENSIONAL

Figura 3.6: Modelo dimensional completo.

3.2. EJEMPLO DE BODEGAS DE PRODUCTOS

17

3. Obtener el total de unidades vendidas del producto con SKU=12345 en el trimestre 1 de 1999. 4. Obtener la diferencia entre las ventas en pesos y el costo de lo vendido por departamento y por tienda. 5. Determinar cual es el mes en el que se venden más productos de la Categoría=”Pañales”, agrupado por tienda. 6. Obtener en orden descendente las promociones más exitosas (de acuerdo a Ventas_Pesos). 7. Asumiendo que la Categoría=”Cerveza” tiene como Subcategorías=”Cerveza Clara”,”Cerveza Oscura”,”Cerveza Light”, ”Cerveza Sin Alcohol”. Determine cuantos clientes compraron simultaneamente ”Cerveza Clara” y ”Cerveza Oscura”.

3.2.

Ejemplo de bodegas de productos

Se tiene un conjunto de bodegas donde se almacenan diversos productos. Considerando un modelo muy simple asumamos que solo es necesario llevar el numero de productos en existencia de cada producto, por día en cada una de las bodegas. Un modelo dimensional simple podría ser el ilustrado en la figura 3.7 Obtener un reporte en el que se ilustre Unidades por producto, por bodega y por año. En este modelo tenemos un caso interesante, mientras en el modelo de las cadenas de tiendas la cantidad de productos es ADITIVA, en el caso del modelo de bodegas no se tiene esta propiedad, ya que no es posible sumar directamente los niveles de inventario por día. Lo que si se podría hacer es calcular por ejemplo el promedio de unidades en existencia (por producto, por tiempo, por bodega o combinaciones). En este sentido es importante identificar que tipo de operaciones es posible aplicar a los atributos de la tabla de hechos (Suma, Cuenta, Promedio, etc.). Ahora, el modelo dimensional simple de las bodegas no es muy útil puesto que no permite tener una idea clara de como se mueven los productos (rotación de inventarios) y cuantos días de suministro se tienen . Para el cálculo de la rotación de inventarios y de los días de suministro es necesario llevar la información de unidades vendidas por día. El modelo dimensional correspondiente es ilustrado en la figura 3.8.

3.2.1.

Ejemplos de consultas

Dado el modelo dimensional el número de vueltas del inventario por día será: Unidades_Vendidas / Unidades. El número de días de suministro será simplemente: Unidades/Unidades_Vendidas.

18

CAPÍTULO 3. DISEÑO DIMENSIONAL

Figura 3.7: Modelo dimensional simple de un conjunto de bodegas de productos

3.2. EJEMPLO DE BODEGAS DE PRODUCTOS

19

Figura 3.8: Modelo dimensional incluyendo el atributo de unidades vendidas.

20

CAPÍTULO 3. DISEÑO DIMENSIONAL

Para el cálculo de estas medidas con un rango de tiempo más grande es fundamental el reconocer que los cocientes a considerar deberán ser los promedios. Por ejemplo el número de vueltas por año será: (Suma de Unidades_Vendidas en el año)/(Promedio de Unidades diarias). 1. Obtenga el número de vueltas por año de todos los productos de la bodega=”bod1” 2. Obtenga el número de días de suministro que se tuvo el día último del año 1999 considerando un rango de tiempo de un año.

3.3.

Tablas de hechos y tablas de dimensiones

La idea fundamental del modelado dimensional es que los datos de una empresa pueden ser representados por una especie de hipercubo, donde las celdas del hipercubo contienen hechos que ocurren en la empresa. Dicho hipercubo puede constar en algunos casos de 20 dimensiones.

3.3.1.

Hechos

Un modelo dimensional distingue entre hechos y atributos. Un hecho es algo que no es conocido de antemano, es el registro histórico de algo que ocurre en la empresa. Típicamente un hecho tiene un valor numérico (aunque hay casos donde el valor es texto) y además debe tener la propiedad de aditividad (suma y cuenta) o semiaditividad (promedios).

3.3.2.

Atributos

Los atributos son normalmente de tipo texto y son usado para describir las características de un evento.

3.3.3.

Dimensiones

Los atributos son agrupados en dimensiones. Una dimensión es una clasificación que permite conjuntar diferentes atributos que caracterizan un evento que ocurre dentro de una empresa.

3.4.

Drilling Up and Drilling Down

Una característica fundamental del modelado dimensional es que todos los atributos de cada una de las dimensiones es candidato a aparecer dentro de un reporte tabular. Para construir un reporte tabular que muestre tanto campos de las tablas de dimensiones como de la tabla de hechos se puede utilizar SQL. Normalmente se usa de la forma: SELECT campos_hechos, campos_dimensiones

3.4. DRILLING UP AND DRILLING DOWN Departamento D1 D1 D2 D2 D2 D3 D3

Categoría C1 C2 C4 C5 C6 C7 C8

21 Ventas_Pesos 100 200 50 20 30 50 70

Cuadro 3.1: Reporte Tabular de la Cadena de Tiendas Departamento D1 D1 D1 D1 D2 D2 D2 D2 D2 D2 D2 D3 D3 D3 D3

Categoría C1 C1 C2 C2 C4 C4 C5 C5 C6 C6 C6 C7 C7 C8 C8

Subcategoría S1 S2 S3 S4 S5 S6 S7 S8 S9 S10 S11 S12 S13 S14 S15

Ventas_Pesos 70 30 50 150 20 30 15 5 15 10 5 40 10 50 20

Cuadro 3.2: Reporte Tabular de la Cadena de Tiendas Haciendo Drilling Down FROM tabla_hechos, tablas_dimensiones WHERE condicion GROUP BY campos_dimenensiones ORDER BY campos_dimensiones Los campos seleccionados pueden incluir el uso de operadores como DISTINCT, SUM, COUNT, AVERAGE, etc. El significado (en terminos de un reporte tabular) de las operaciones de Drilling Down y de Drilling Up es respectivamente el de agregar columnas y quitar columnas. Por ejemplo respecto al modelo dimensional de la cadena de tiendas ilustrado en la figura 3.6, podemos tener un reporte como el ilustrado en la tabla 5.1 El hacer una operación de Drilling Down sobre los datos de la tabla 5.1, nos daría mas detalles y esto se podría lograr agregando la columna de subcategoría, esto se ilustra en la tabla 5.2.

22

CAPÍTULO 3. DISEÑO DIMENSIONAL Departamento D1 D2 D3

Ventas_Pesos 300 100 120

Cuadro 3.3: Reporte Tabular de la Cadena de Tiendas Haciendo Drilling UP El hacer una operación de Drilling Up sobre los datos de la tabla 5.1 nos permitiría eliminar detalles, esto implica eliminar alguna columna, si eliminamos la columna de categoría tendríamos los resultados presentados en la tabla 5.3

3.5.

Dimensiones Cambiantes

Normalmente se piensa que la llave asociada a una dimensión no cambia, pero en la vida real es posible que esto si ocurra. En este sentido hay tres alternativas básicas que se pueden manejar: 1. Reescribir los registros de dimensiones con los nuevos valores y de este modo perder la historia. 2. Crear un registro adicional por cada registro que cambio su llave y agregarle una nueva llave, de esta manera podemos tener accesible el registro histórico. 3. Crear dentro de la tabla de dimensiones un campo que se llame ”anterior” que permita llevar el valor anterior de la llave. Como puede deducirse el tipo de manejo más conveniente es el tipo 2.

3.6.

Dimensiones degeneradas

En la venta de productos es común que se utilice un número de venta, este número de venta permite agrupar diferentes productos, de manera tal que lo más razonable es que este número de venta sea incluido en la tabla de hechos. Pero el detalle está en que este atributo de número de venta no tiene asociada ninguna tabla de dimensiones. A esto se le conoce como una dimensión degenerada puesto que solo tenemos la llave, pero ningún otro atributo asociado.

3.7.

Aditividad

Siempre que sea posible, los hechos en la tabla de hechos deben ser seleccionados para ser aditivos respecto a todas las dimensiones. Existen, sin embargo, casos en los que los hechos son semiaditivos respecto a alguna dimensión, por ejemplo la temperatura respecto al tiempo, en este caso no podemos sumar las temperaturas, pero si las podemos promediar.

3.8. TABLAS DE HECHOS SIN HECHOS

23

Figura 3.9: Modelo dimensional ilustrando una tabla de hechos sin hechos

3.8.

Tablas de hechos sin hechos

Normalmente cada tabla de hechos tiene, además de las llaves heredadas de las dimensiones, uno o más atributos numéricos que definen la ocurrencia de un evento (cantidad de items vendidos, cantidad de dinero, etc.), más sin embargo en ocasiones la tabla de hechos sólo está compuesta de las llaves heredadas de la tabla de dimensiones. Es decir la información es solo la ocurrencia del evento. En esta situación normalmente se usa como operador aditivo el contar cuantos registros existen en la tabla de hechos (o agregar un campo que siempre tenga un valor de 1 para poder usar sumas). Un ejemplo de esto es la asistencia de un alumno a una determinada clase, el modelo dimensional correspondiente se ilustra en la figura 3.9

24

CAPÍTULO 3. DISEÑO DIMENSIONAL

Figura 3.10: Modelo dimensional de un hospital Algunas consultas típicas sobre el modelo dimensional de la figura 3.9 pueden ser: 1. Cuáles son las clases con más asistencias. 2. Cuáles profesores enseñan al mayor número de alumnos. 3. Cuáles salones son los menos usados.

3.9.

Dimensiones N_a_N

Normalmente cada una de los hechos dentro de la tabla de hechos tiene asociado una llave proveniente de cada una de las tablas de dimensiones. Pero en ocasiones un solo hecho puede tener múltiples instancias de llaves de una tabla de dimensiones. Por ejemplo en el modelo dimensional de la figura 3.10 dónde se lleva el control de la la cantidad cobrada a un paciente por su atención, solo es posible introducir un diagnóstico, pero en ocasiones en un ingreso a un paciente se le atiende por varios (un número no definido) de diagnósticos. ¿Qué hacer ?. Una solución sería agregar múltiples tablas de diagnósticos para tener múltiples llaves en la tabla de hechos respecto a diagnósticos. Una mejor solución (dado que no sabemos el total de posibles diagnósticos de un paciente) es agregar una tabla puente entre la dimensión Diagnóstico y

3.9. DIMENSIONES N_A_N

25

la tabla de hechos Cuenta, esto es ilustrado en la figura 3.11. Es importante observar que el atributo porcentaje en la tabla puente permite obtener la parte de Total que corresponde a cada uno de los diagnósticos.

26

CAPÍTULO 3. DISEÑO DIMENSIONAL

Figura 3.11: Modelo dimensional usando una tabla puente para múltiples diagnósticos.

Capítulo 4

Integración de Esquemas 4.1.

Introducción

En este capítulo se tratarán los aspectos relacionados con la integración de múltiples fuentes de datos (normalmente heterogéneas) en una fuente de datos única (la bodega de datos). Aun cuando existen diversos enfoques para la realización de la integración de esquemas (basados en vistas, basados en lógica de primer orden, basados en enfoques evolutivos, etc.), este capítulo se concentra en presentar un enfoque basado en la semántica (significado) de los datos.

4.2.

Semántica

El primer punto importante es: ¿Qué es la semántica?. El significado y uso de los datos. El mapeo entre un objeto modelado y el objeto del mundo real que representa. Requiere de un agente de interpretación que derive el significado de algún objeto y adicionalmente para que tenga sentido, se requiere de un acuerdo (formal o informal) entre agentes respecto a la interpretación. Ahora, en el contexto que nos ocupa, lo importante es la semántica de los datos, una manera de ubicar la semántica es a través de los METADATOS (es decir datos que explican a los datos). Un metadato es independiente del contenido básico, pero describe las características de los datos y su estructura.

4.3.

Propósito de la Integración de Esquemas

Una manera simple de ubicar la integración de esquemas es: La identificación de objetos que están semánticamente relacionados y se encuen27

28

CAPÍTULO 4. INTEGRACIÓN DE ESQUEMAS

tran almacenados en diversas bases de datos, y después resolver las diferencias esquemáticas para hacerlos en cierto sentido equivalentes.

4.4.

Proximidad Semántica

Definamos la proximidad semántica entre dos objetos como: SemPro(Objeto1 ,Objeto2 )=Contexto, Abstracción, (Dominio1 , Dominio2 ), (Estado1 ,Estado2 ) Donde: Contexto: Se refiere al contexto específico en el que se da una similaridad semántica, este contexto puede estar relacionado o ser diferente a los contextos en los que están definidos los objetos. Abstracción: Se refiere al mecanismo usado para mapear los dominios de los dos objetos. (Dominio1 , Dominio2 ): Se refieren a los conjuntos de valores que puede tomar cada objeto. (Estado1 ,Estado2 ): Se refiere a la extensión de los objetos.

4.4.1.

Contexto

Es posible que dos objetos estén relacionados de manera diferente de acuerdo al contexto, v.g. en un contexto dos empleados de una empresa (uno que barre y el director general) están semánticamente cerca (por ejemplo pago de impuestos), pero en otro contexto podrán estar más separados (en la responsabilidad y prestaciones que tienen). Aunque es posible crear diversas clasificaciones de contextos, consideraremos que los posibles contextos son: TODOS. La proximidad semántica de los objetos se da en todos los posibles contextos. En este sentido no necesita ser definido el contexto específico. MISMO. Los objetos involucrados en la proximidad semántica están definidos en el mismo contexto. El contexto necesita ser definido explicitamente. ALGUNOS. La proximidad semántica se da en más de un contexto. Los contextos aplicables deben ser explicitados. NINGUNO. Los objetos bajo consideración no exhiben ninguna proximidad semántica útil bajo ningún contexto. Un detalle importante es que la definición de los contextos de los dominios debe ser definido por un usuario, no existe reportado a la fecha una manera automática de extraer los contextos de los objetos y relacionarlos.

4.4. PROXIMIDAD SEMÁNTICA

4.4.2.

29

Abstracción

Los posibles valores de abstracción para mapear los dominios de los objetos son: Mapeo Total 1-a-1(Biyección). Para cada valor de un dominio existe uno y solo un valor correspondiente en el otro dominio y visceversa. Mapeo Parcial 1-a-1. Similar al anterior, pero quedan objetos en uno o en ambos dominios sin ser mapeados. Mapeo Total N-a-1. En este caso cada valor de un dominio está asociado con múltiples valores del otro dominio y varios valores del segundo dominio están asociados con un sólo valor del primer dominio. Este tipo de mapeo está relacionado con la generalización o especialización de dominios. Mapeo Parcial N-a-1. Es similar al caso anterior, pero existen algunos elementos en uno o en los dos dominios que no son mapeados. CUALQUIERA. Indica que puede usarse cualquier abstracción de las anteriores. NINGUNA. Indica que no se conoce un mapeo definido entre los dominios de los objetos semánticamente relacionados. INEXISTENTE. Indica que no existe mapeo posible entre dos objetos (i.e. no están semánticamente relacionados).

4.4.3.

Dominios

El dominio de un objeto es el conjunto de todos sus posibles valores. Si se usa un tipo básico para definirlo como INTEGER, entonces el dominio corresponde a todos los posibles valores que se pueden representar con un INTEGER (de acuerdo a la precisión usada), si se usa un tipo no-básico, entonces los posibles valores deben seguir ciertas reglas (por ejemplo una FECHA restringe los dias de un mes de acuerdo al valor del mes y del año). Aún cuando dos objetos tengan diferente dominio, es posible que están semánticamente muy cerca, por ejemplo es posible que un objeto tenga una fecha en formato CHAR, otro objeto tenga la fecha en formato DATE, otro objeto tenga la fecha en formato NUMBER (comó el número de días transcurridos a partir de cierta fecha) y ser compatibles semánticamente.

4.4.4.

Estados

El estado de los objetos se refiere a su extensión es decir el valor específico que toman. Es importante recalcar que dos objetos con diferente estado pueden ser semánticamente equivalentes.

30

4.5.

CAPÍTULO 4. INTEGRACIÓN DE ESQUEMAS

Equivalencia Semántica

Está es la proximidad semántica mayor que puede haber entre dos objetos. Dos objetos son semánticamente equivalentes si representan el mismo objeto de la vida real. Existen dos maneras de ver esta equivalencia, al nivel de dominios y al nivel de estados, la equivalencia a nivel dominios es: SemPro(Objeto1 ,Objeto2 )=TODOS, Mapeo Total 1-a-1, (Dominio1 , Dominio2 ), _ Y la equivalencia a nivel estados: SemPro(Objeto1 ,Objeto2 )=TODOS, Mapeo Total 1-a-1, (Dominio1 , Dominio2 ), (Estado1 ,Estado2 )

4.6.

Relación Semántica

Este es un tipo de similaridad semántica más débil que la equivalencia semántica. Se dice que dos objetos están semánticamente RELACIONADOS si existe un mapeo parcial 1-a-1, mapeo total N-a-1 ó mapeo parcial N-a-1 entre los dominios de los objetos. Esto puede definirse como: SemPro(Objeto1 ,Objeto2 )=TODOS, M, (Dominio1 , Dominio2 ),_ Donde M =mapeo parcial 1-a-1, mapeo total N-a-1 ó mapeo parcial N-a-1.

4.7.

Relevancia Semántica

Dos objetos son semánticamente relevantes si pueden ser relacionados entre sí usando alguna forma de abstracción (mapeo) y el mismo contexto. Esto puede definirse como: SemPro(Objeto1 ,Objeto2 )=MISMO, CUALQUIERA, (Dominio1 , Dominio2 ),_

4.8.

Parecido Semántico

Está es la forma más débil de proximidad semántica. En este caso dos objetos no pueden ser relacionados de acuerdo al contexto o de acuerdo a los posibles mapeos entre sus dominios. La única manera de establecer la proximidad semántica es a través del análisis de las extensiones de los objetos. Para definir el parecido semántico usaremos el concepto de rol. El rol de un objeto especifica la relación existente entre un objeto y el contexto al que pertenece, esto puede definirse como: Rol : objeto × contexto→ nombre de rol En general está relación puede ser multivaluada, i.e. un objeto puede tener más de un rol en el mismo contexto, más sin embargo consideraremos que la relación es univaluada por sencillez. Entonces podemos especificar el parecido semántico como:

4.9. INCOMPATIBILIDAD SEMÁNTICA

31

SemPro(Objeto1 ,Objeto2 )=Contexto, NINGUNO, (Dominio1 , Dominio2 ),_ donde Contexto=Contexto(Objeto1 ) ∪ Contexto(Objeto2 ) y Dominio1 6= Dominio2 y Rol(Objeto1 , Contexto)=Rol(Objeto2 ,Contexto) Un ejemplo de parecido semántico puede darse entre los empleados de diferentes empresas respecto a un contexto de pago de impuestos (Hacienda), es decir no existe mapeo entre los objetos de diferentes empresas, más sin embargo bajo la premisa del Rol Contribuyente existe un parecido semántico entre todos los empleados de diversas empresas.

4.9.

Incompatibilidad Semántica

El no conocer una similaridad semántica entre dos objetos no implica de manera automática que los objetos son semánticamente incompatibles. El definir la incompatibilidad semántica entre dos objetos implica que no existe contexto, no existe mapeo, y no existen roles bajo los cuales sea posible establecer una similaridad semántica. Podemos expresar esto como: SemPro(Objeto1 ,Objeto2 )=NINGUNO, INEXISTENTE, (Dominio1 , Dominio2 ),_ donde Contexto=Contexto(Objeto1 ) ∪ Contexto(Objeto2 ) está indefinido y Dominio1 6= Dominio2 y Rol(Objeto1 , Contexto) y Rol(Objeto2 ,Contexto) no son comparables.

4.10.

Incompatibilidad de Dominios

La figura 4.1 identifica las instancias del problema de incompatibilidad de dominios que trataremos en mayor detalle en esta sección.

4.10.1.

Conflictos de Nombres

Existen básicamente dos casos: a) Sinónimos, cuando dos objetos tienen diferentes atributos, pero son equivalentes; y b)Homónimos, cuando dos objetos tienen los mimos atributos pero no son equivalentes. Un ejemplo de sinónimos: Empleado(NumEmp, Salario) y Empleado(#Emp, Paga). Un ejemplo de homónimos: Estudiante(Identificador, Nombre) y Libro(Identificador, Nombre)

4.10.2.

Conflictos de Representación de Datos

Dos atributos que son semánticamente similares pueden tener diferente tipo de datos (o dominio) y entonces deben definirse rutinas de conversión entre los

32

CAPÍTULO 4. INTEGRACIÓN DE ESQUEMAS

Figura 4.1: Casos de la incompatibilidad de dominios

4.11. INCOMPATIBILIDAD DE DEFINICIÓN DE ENTIDADES

33

tipos de datos (dominios). Un ejemplo sería: el atributo de Edad en un objeto es CHAR y en otro objeto es NUMBER

4.10.3.

Conflictos de Escala de Datos

Se refiere a la representación de un atributo en diferentes Unidades o Escalas. Por ejemplo el salario expresado en Pesos ó en Libras Esterlinas. Este tipo de conflicto es resuelto usando una rutina de equivalencia o una tabla de equivalencia. Esto implica una correspondencia 1-a-1.

4.10.4.

Conflictos de Precisión de Datos

Se refiere a que dos atributos con cierta similaridad semántica son expresados usando diferente precisión, la diferencia con el caso anterior es que en este caso la correspondencia es de N-a-1 y no de 1-a-1. Un ejemplo sencillo es el atributo de calificación, en un objeto se maneja de acuerdo a: {A,B,C,D,E} y en otro objeto de acuerdo a un número entre 1 y 100.

4.10.5.

Conflictos de Valor por Omisión

En este caso los objetos tienen definidos diferentes valores por omisión en diferentes bases de datos. Aunque en general no es posible definir un mapeo que resuelva este conflicto, si es posible que bajo el MISMO contexto sea posible definir la correspondencia entre los objetos en conflicto. Un caso concreto podría ser el atributo de Edad que en una base de datos el valor por omisión sea 18 y en otra sea 21.

4.10.6.

Conflictos de Restricciones de Integridad

Aunque en general dos objetos con similaridad semántica pero con conflictos de restricciones de integridad no son compatibles, bajo ciertos contextos y usando los roles es posible establecer un parecido semántico entre los objetos.

4.11.

Incompatibilidad de Definición de Entidades

La figura 4.2 identifica las instancias del problema de incompatibilidad de entidades que se trataran en esta sección.

4.11.1.

Conflictos de Identificador de Bases de Datos

Este problema ocurre cuando en la llave de entidades semánticamente relacionadas es diferente. Por ejemplo en una base de datos la entidad Estudiante tiene como llave un número conocido como matrícula y en otra base de datos la entidad Estudiante tiene como llave el nombre del estudiante. En este sentido es

34

CAPÍTULO 4. INTEGRACIÓN DE ESQUEMAS

Figura 4.2: Casos de Incompatibilidad en Definición de Entidades posible definir el parecido semántico bajo el rol de que la matricula y el nombre son equivalentes.

4.11.2.

Conflictos de Nombres

Se refiere a que dos entidades con diferente nombre son equivalentes (sinónimos) y a que dos entidades con igual nombre son incompatibles semánticamente (homónimos).

4.11.3.

Conflictos de Compatibilidad a la Unión

Estos conflictos ocurren cuando dos entidades con cierta proximidad semántica no tienen los mismos atributos, pero es posible establecer una relación semántica entre los atributos que son correspondientes. Por ejemplo la entidad Estudiante(Matricula, Nombre, Carrera) y la entidad Estudiante(Matricula, Nombre, Dirección) no son compatibles a la unión pero se puede establecer una relación semántica con los campos equivalentes.

4.11.4.

Conflictos de Isomorfismos de Esquemas

Entidades semánticamente similares pueden tener diferente número de atributos para representar situaciones similares dando lugar a conflictos de isomorfismos de esquemas. Por ejemplo las entidades Estudiante(Matricula, TelefonoCasa, TelefonoTrabajo) y Estudiante(Matricula, Telefono) tienen un conflicto de isomorfismo de esquemas. Esto puede ser resuelto estableciendo un mapeo entre los dos telefonos de la primer entidad y el telefono de la segunda entidad.

4.12. INCONSISTENCIA

4.11.5.

35

Conflictos de Datos Faltantes

Este conflicto ocurre cuando una de las entidades carece de un atributo que esta presente en la otra entidad. Este conflicto puede resolverse y establecerse entonces la relevancia semántica si existe algun procedimiento para deducir el valor del atributo faltante. Por ejemplo la entidad Estudiante(Matricula, Nombre, Graduado) y Estudiante(Matricula, Nombre) son susceptibles para resolver el conflicto si es posible en la segunda entidad derivar el valor del atributo Graduado (i.e. que cursó y aprobó todas las materias de su plan de estudios).

4.12.

Inconsistencia

Existe la posibilidad de que al integrar dos o más bases de datos surjan problemas de inconsistencia (por ejemplo que el mismo objeto tenga asociados atributos equivalentes, pero con diferente valor). En este contexto es posible que se tenga alguno de los siguientes casos: 1. Inconsistencia Conocida. Se sabe que una de las bases de datos es más confiable que la otra, de manera tal que en caso de inconsistencia se escoja el valor de la base de datos más confiable. 2. Inconsistencia Temporal. Se tiene información que tiene un contexto temporal, en este caso se podría integrar la información pero manejando una tabla bitemporal ó se podría tomar la información más reciente. 3. Inconsistencia Aceptable. Se da cuando el rango de inconsistencia es tolerable, por ejemplo que los ingresos totales difieran en 25 centavos ó que la ciudad de residencia sea diferente pero el estado sea el mismo (considerando que es más relevante el estado).

4.13.

Incompatibilidad por Nivel de Abstracción entre Entidades

Es posible que dos entidades que tienen cierta similaridad semántica adolezcan del problema de nivel de abstracción, básicamente hay dos casos: a)que en una entidad sea la generalización de la otra; y b) que una entidad sea resultado de la agregación de la otra. El caso de la generalización puede ser ilustrado de acuerdo a las entidades(de un programa de posgrado): Estudiante(Matricula, Nombre, Carrera) y Estudiante(Matricula, Nombre, Carrera, Asesor), la primer entidad es una generalización de la segunda. (RELACION SEMANTICA) El caso de la agregación puede ser ilustrado con el siguiente ejemplo: Carga(Camión, PromedioPeso) y Paquete(Camión, Peso). (RELACION SEMANTICA).

36

CAPÍTULO 4. INTEGRACIÓN DE ESQUEMAS

4.14.

Problema de Discrepancia Esquemática

Este problema ocurre cuando dos entidades representan la misma situación del mundo real pero usando diferentes esquemas. Por ejemplo las acciones que cotizan en la bolsa y su precio de cierre cada día pueden ser representadas de acuerdo a: 1. ENT1(Fecha, IdAcción, PrecioCierre). Un registro por acción por día. 2. ENT2(Fecha, Acción1, Acción2, .....). Un registro por cada día. 3. {Acción1(Fecha, PrecioCierre), Acción2(Fecha,PrecioCierre), ....} Una tabla para cada Acción. 4. ENT3(IdAcción,01_ENE_1930, 02_ENE_1930,....,01_ENE_2000, ....) Un registro para cada acción. 5. ENT4(IdAcción,Año,Mes, Dia1, Dia2, Dia3,...,Dia31) Un registro por cada mes de una acción. 6. {01_ENE_1930(IdAcción, PrecioCierre), ..., 01_ENE_2000(Id_Acción, Precio_Cierre), ....} Una tabla para cada Día 7. {Acción1(01_ENE_1930, ..., 01_ENE_2000, ..., ), Acción2(01_ENE_1930, ..., 01_ENE_2000, ....), ... } Una tabla para cada Acción con un solo registro(una columna para cada Día). 8. {01_ENE_1930(Acción1, Acción2, ...), ..., 01_ENE_2000(Acción1, Acción2, ...), ....} Una tabla para cada Día con un sólo registro(una columna para cada acción).

4.14.1.

Conflicto Valor Dato-Atributo

Ocurre cuando los valores de un atributo se convierten en atributos en otra entidad. Esto ocurre entre ENT1 y ENT2 ó ENT1 y ENT3. La proximidad semántica se define como: SemPro(Objeto1 ,Objeto2 )=TODOS, M, (Dominio1 , Dominio2 ),(Estado1 , Estado2 ) Donde M define un mapeo total 1-a-1 entre el conjunto de valores de un atributo de una tabla y los atributos de la otra tabla.

4.14.2.

Conflicto Atributo-Entidad

Este problema ocurre cuando los atributos de una tabla en una base de datos corresponden a un conjunto de tablas en la otra base de datos. Esto ocurre entre ENT2 y la representación 3, ó entre ENT3 y la representación 5. SemPro(Objeto1 ,Objeto2 )=TODOS, M, (Dominio1 , Dominio2 ),_ Donde M define un mapeo total 1-a-1 entre los atributos de una tabla en la primer base de datos y el conjunto de tablas de la segunda base de datos.

4.15. TAREA

4.14.3.

37

Conflicto Valor Dato - Entidad

Este problema ocurre cuando los valores de un atributo en una entidad de una base de datos se convierten en entidades en otra base de datos. Esto ocurre por ejemplo entre ENT1 y la representación 3 ó ENT1 y la representación 5.

4.15.

Tarea

Proponga un metamodelo (sugerencia usar ER) que proporcione soporte para la integración de esquemas usando el concepto de proximidad semántica(es decir involucre por lo menos el concepto de Contexto, Abstracción, Dominios, Estados, Roles, etc.). Es fundamental que el metamodelo integre la mayor semántica posible para facilitar el proceso de integración.

38

CAPÍTULO 4. INTEGRACIÓN DE ESQUEMAS

Capítulo 5

Tablas Temporales En este capítulo presentaremos algunos detalles relativos al manejo de tablas que involucran el manejo de uno o más campos de tipo temporal. Los campos de tipo temporal pueden ser: Fecha, Hora o TimeStamp (Fecha y Hora). Este tipo de tablas tienen características especiales que merecen su estudio de manera independiente, por otro lado al recordar que el contenido de una bodega de datos es típicamente el resultado de acumular históricamente una serie de eventos es fundamental el poder manejar de manera correcta casos como: a) Inicio de un evento; b) Fin de un evento; c)Duración de un Evento; d) Período de validez de un evento; etc.

5.1.

Tipos de Datos para Manejo de Tiempo

Aunque es posible que el soporte de tipos de datos pueda variar de acuerdo al manejador de base de datos, Oracle soporta los tipos de datos: Date (Fecha). Para poder llevar el control del día, mes y año de un evento. TimeStamp. Para llevar la hora y fecha de un evento.

5.2.

Funciones Para Manejo de Tiempo en Oracle

Oracle soporta las siguientes funciones para el manejo de tiempo: Year. Permite obtener el número de año. Month. Permite obtener el número de mes. DayOfMonth. Permite obtener el número del día del mes. LastDay. Permite obtener la fecha del último día del mes. 39

40

CAPÍTULO 5. TABLAS TEMPORALES DayOfWeek. Permite obtener el número del día de la semana. DayOfYear. Permite obtenere el número del día del año. Hour. Obtiene la hora. Minute. Obtiene los minutos. Second. Obtiene los segundos. Next_Day. Regresa la fecha que corresponde al siguiente día de la semana indicado. Quarter. Regresa el número de trimestre. Months_Between. Indica el número de meses entre dos fecha (considera meses de 31 días). Interval. Permite especificar un intervalo de tiempo. Between. Predicado que indica si una fecha está entre dos. To_Char. Conversión de fecha a caracter.

5.2.1.

Inicialización de una Tabla Temporal

Para ilustrar el uso de estas funciones, asume que se ejecutan los siguientes comandos: CREATE TABLE POBLA ( NOMBRE char(35) PRIMARY KEY, NACE timestamp NOT NULL, MUERE timestamp DEFAULT ’31-Dec-4000’ NOT NULL); INSERT INTO POBLA (NOMBRE, NACE) VALUES (’Pedro Perez’, ’01-Jan-2000 03:12:04’); INSERT INTO POBLA (NOMBRE, NACE) VALUES (’Juan Lopez’, ’11-Feb-1999 19:40:12’); INSERT INTO POBLA (NOMBRE, NACE) VALUES (’Luis Fuentes’, ’21-Mar-1998 07:12:35’); INSERT INTO POBLA (NOMBRE, NACE) VALUES (’Ramiro Anaya’, ’30-Apr-1997 14:32:01’); INSERT INTO POBLA (NOMBRE, NACE) VALUES (’Ana Martinez’, ’17-Jun-1996 21:58:02’); INSERT INTO POBLA (NOMBRE, NACE) VALUES (’Elena Spiegel’, ’08-Dec-1995 08:01:03’); INSERT INTO POBLA (NOMBRE, NACE) VALUES (’Laura Rodriguez’, ’15-Nov-1994:01:02:04’); COMMIT;

5.2. FUNCIONES PARA MANEJO DE TIEMPO EN ORACLE

5.2.2.

41

Manipulación de una Tabla Temporal

Después de esto pruebe ejecutar las siguientes consultas. Consulta 1 SELECT RTRIM(NOMBRE) AS NOMBRE, TO_CHAR(NACE) AS NACE FROM POBLA; Ver resultados en 5.1. NOMBRE Pedro Perez Juan Lopez Luis Fuentes Ramiro Anaya Ana Martinez Elena Spiegel Laura Rodriguez

NACE 2000-01-01 1999-02-11 1998-03-21 1997-04-30 1996-06-17 1995-12-08 1994-11-15

03:12:04.000000 19:40:12.000000 07:12:35.000000 14:32:01.000000 21:58:02.000000 08:01:03.000000 00:00:00.000000

Cuadro 5.1:

Consulta 2 SELECT * FROM POBLA WHERE NACE = ’01-JAN-2000 03:12:04’; Ver tabla 5.2 NOMBRE Pedro Perez

NACE 2000-01-0

MUERE 4000-12-3

Cuadro 5.2:

Consulta 3 SELECT * FROM POBLA WHERE {FN YEAR(NACE)}  2000; Ver tabla 5.3 NOMBRE Juan Lopez Luis Fuentes Ramiro Anaya Ana Martinez Elena Spiegel Laura Rodriguez

NACE 1999-02-1 1998-03-2 1997-04-3 1996-06-1 1995-12-0 1994-11-1

Cuadro 5.3:

MUERE 4000-12-3 4000-12-3 4000-12-3 4000-12-3 4000-12-3 4000-12-3

42

CAPÍTULO 5. TABLAS TEMPORALES

Consulta 4 SELECT * FROM POBLA WHERE {FN MONTH(NACE)}  12; Ver tabla 5.4 NOMBRE Pedro Perez Juan Lopez Luis Fuentes Ramiro Anaya Ana Martinez Laura Rodriguez

NACE 2000-01-0 1999-02-1 1998-03-2 1997-04-3 1996-06-1 1994-11-1

MUERE 4000-12-3 4000-12-3 4000-12-3 4000-12-3 4000-12-3 4000-12-3

Cuadro 5.4:

Consulta 5 SELECT {FN YEAR(NACE) } AS YY, {FN MONTH(NACE) } AS MM, {FN DAYOFMONTH(NACE) } AS DD, {FN DAYOFMONTH(LAST_DAY(NACE)) } AS ULT_MES, {FN WEEK(NACE) } AS SEM, {FN DAYOFWEEK(NACE) } AS DIASEM, {FN DAYOFYEAR(NACE) } AS DIAYEAR, {FN HOUR(NACE) } AS HH, {FN MINUTE(NACE) } AS MM, {FN SECOND(NACE) } AS SS FROM POBLA; Ver tabla 5.5 YY 2000 1999 1998 1997 1996 1995 1994

MM 1 2 3 4 6 12 11

DD 1 11 21 30 17 8 15

ULT_MES 31 28 31 30 30 31 30

SEM 1 7 12 18 25 49 47

Cuadro 5.5:

DIASEM 7 5 7 4 2 6 3

DIAYEAR 1 42 80 120 169 342 319

HH 3 19 7 14 21 8 0

MM 12 40 12 32 58 1 0

SS 4 12 35 1 2 3 0

5.2. FUNCIONES PARA MANEJO DE TIEMPO EN ORACLE

43

Consulta 6 SELECT {FN TO_CHAR(NACE, ’MM DD YYYY’) } AS NACE, {FN TO_CHAR(NEXT_DAY(NACE,’WEDNESDAY’), ’MM DD YYYY’) } AS SIG_MIERCOLES FROM POBLA; Ver tabla 5.6 NACE 01 01 2000 02 11 1999 03 21 1998 04 30 1997 06 17 1996 12 08 1995 11 15 1994

SIG_MIERCOLES 01 05 2000 02 17 1999 03 25 1998 05 07 1997 06 19 1996 12 13 1995 11 16 1994 Cuadro 5.6:

Consulta 7 SELECT {FN QUARTER(NACE) } AS TRIMESTRE, {FN MONTHS_BETWEEN(MUERE,NACE) } AS MESES_VIDA FROM POBLA; Ver tabla 5.7 TRIMESTRE 1 1 1 2 2 4 4

MESES_VIDA 24011.963 24022.619 24033.313 24044 24054.422 24060.731 24073.516

Cuadro 5.7:

Consulta 8 SELECT * FROM POBLA WHERE NACE BETWEEN ’01-JAN-1998’ AND ’01-JAN-2000’; Ver tabla 5.8

44

CAPÍTULO 5. TABLAS TEMPORALES NOMBRE Juan Lopez Luis Fuentes

NACE 1999-02-1 1998-03-2

MUERE 4000-12-3 4000-12-3

Cuadro 5.8: Consulta 9 SELECT {FN TO_CHAR(NACE, ’DD MM YYYY’) } AS MM_DD_YYYY, {FN TO_CHAR(NACE+INTERVAL ’2450’ DAY,’DD MM YYYY’) } AS MAS_2450_DIAS FROM POBLA; Ver tabla 5.9 MM_DD_YYYY 01 01 2000 11 02 1999 21 03 1998 30 04 1997 17 06 1996 08 12 1995 15 11 1994

MAS_2450_DIAS 16 09 2006 27 10 2005 04 12 2004 14 01 2004 03 03 2003 23 08 2002 31 07 2001

Cuadro 5.9:

5.3.

Instante

Un instante está definido por una instancia del tipo de datos TimeStamp. Se usa para registrar eventos cómo: a)nacimiento de una persona; b)lanzamiento de un transbordador; c) ocurrencia de un golpe de estado; d)nombramiento del sucesor del papa; etc.

5.4.

Intervalo

Un intervalo está definido por dos instancias de tipo temporal. Permite registrar el inicio y finalización de eventos, por ejemplo: a) intervalo de vida de una persona (nacimiento-muerte); b) duración de un matrimonio; c) tiempo que toma en realizarse una reacción química; etc.

5.5. EVENTOS QUE COMPARTEN UNA FRACCIÓN DE TIEMPO

5.5.

45

Eventos que comparten una fracción de tiempo

Asumamos que i1 e i2 son el inicio de dos eventos y que t1 y t2 sean las terminaciones de los eventos, entonces los dos eventos comparten una fración de tiempo en sus ocurrencias sii: i1 = t2 AND i2 = t1

5.6.

Tarea

Crear e insertar registros a las tablas TAR(IdTar, Dias) y ORDEN(Orden, IdTar, Cantidad, Inicio). La llave de la tabla TAR es IdTar. La llave de la tabla ORDEN está compuesta por los campos: Orden e IdTar. La tabla TAR contiene la lista de productos que pueden ser manufacturados indicando lo que se tarda en días (el campo Días es numérico flotante). La tabla ORDEN contiene las ordenes de producción de productos, una orden involucra un sólo tipo de producto, pero pueden ser múltiples unidades de acuerdo al valor del campo NúmeroProductos. El campo Inicio es de tipo timestamp e indica el instante en el que se inicio la producción de dicha orden. Es importante considerar que el campo Días de la tabla PROD indica el tiempo para producir una unidad. Obtenga en SQL las parejas de Ordenes de producción cuya ejecución comparte una fracción de tiempo. Solución ver comandos en tabla 5.10.

5.7.

Manejo de Intervalos en Oracle

El manejo de intervalos es soportado en Oracles a través del constructor INTERVAL, ó a través de expresiones que manipulen objetos de tipo date o timestamp. Este constructor permite la creación de intervalos de tiempo de diferente granularidad, ver datos en la tabla 5.11.

5.8.

Períodos

Un período representa la duración de un evento en el tiempo. En este sentido un período tiene un inicio y un final. Existen 7 relaciones básicas que pueden darse al relacionar dos períodos. Estas relaciones serán referidas por su nombre en inglés y son representadas en la figura 5.12. Dado que un período puede definirse especificando un inicio y un final ó un inicio y una duración (intervalo de tiempo), podemos entonces decir que un período está comprendido entre dos eventos de tipo temporal digamos 1 y 2 ó un evento de inicio y un intervalo digamos 1 y  . Pero como podrá identificarse rapidamente tenemos ambigüedad al no tener claramente definido si el período

46

CAPÍTULO 5. TABLAS TEMPORALES

Comando DROP TABLE ORDEN; DROP TABLE TAR; CREATE TABLE TAR (IDTAR INTEGER PRIMARY KEY, Dias NUMBER NOT NULL); CREATE TABLE ORDEN (ORDEN INTEGER , IDTAR INTEGER , INI TIMESTAMP NOT NULL, CANTIDAD NUMBER); ALTER TABLE ORDEN ADD( PRIMARY KEY (ORDEN,IDTAR)); ALTER TABLE ORDEN ADD(FOREIGN KEY (IDTAR) REFERENCES TAR); INSERT INTO TAR VALUES (1, 3.25); INSERT INTO TAR VALUES (2, 8.189); INSERT INTO TAR VALUES (3, 3.4321); INSERT INTO TAR VALUES (4, 0.1431); INSERT INTO TAR VALUES (5, 1.29845); INSERT INTO TAR VALUES (6, 2.9458); INSERT INTO TAR VALUES (7, 0.8139); INSERT INTO ORDEN VALUES (1,7,’01-Jan-2000 03:12:04’); INSERT INTO ORDEN VALUES (2,5,’02-Jan-2000 19:40:12’); INSERT INTO ORDEN VALUES (3,3,’02-Jan-2000 07:12:35’); INSERT INTO ORDEN VALUES (4,6,’03-Jan-2000 14:32:01’); INSERT INTO ORDEN VALUES (5,4,’01-Jan-2000 21:58:02’); INSERT INTO ORDEN VALUES (6,2,’02-Jan-2000 08:01:03’); INSERT INTO ORDEN VALUES (7,1,’03-Jan-2000 01:01:02’); SELECT TO_CHAR(O1.INI, ’DD HH:MM:SS’) AS I1, T1.DIAS AS D1, TO_CHAR(O1.INI+T1.DIAS, ’DD HH:MM:SS’) AS F1, TO_CHAR(O2.INI, ’DD HH:MM:SS’) AS I2, T2.DIAS AS D2, TO_CHAR(O2.INI+T2.DIAS, ’DD HH:MM:SS’) AS F2, O1.ORDEN AS O1, O2.ORDEN AS O2 FROM ORDEN O1, ORDEN O2, TAR T1, TAR T2 WHERE O1.IDTAR=T1.IDTAR AND O2.IDTAR=T2.IDTAR AND O1.ORDENO2.ORDEN AND O1.INI  O2.INI+T2.DIAS*O2.CANTIDAD AND O2.INI  O1.INI+T1.DIAS*O1.CANTIDAD; Cuadro 5.10: Solución Tarea Manejo de Traslapes

5.8. PERÍODOS

47

Expresión INTERVAL ’7’ DAY INTERVAL ’2 12’ DAY TO HOUR-INTERVAL ’10’ HOUR DATE ’1999-01-01’-DATE ’1997-12-30’

Explicación Especifia intervalo de 7 días Regresa 2 días y 2 horas Regresa 367 días

Cuadro 5.11: Ejemplos de Intervalos

Representación Gráfica

Relación Directa

Relación Inversa

a before b

b before−1 a

a meets b

b meets−1 a

a overlaps b

b overlaps−1 a

a equals b a starts b

b starts−1 a

a finishes b

b finishes−1 a

a during b

b during−1 a

Cuadro 5.12: Relaciones Posibles Entre dos Períodos

48

CAPÍTULO 5. TABLAS TEMPORALES

Relación [1  2 ] equals [1  2 ] [1  2 ] equals [1  2 ) [1  2 ] equals (1   ) [1  2 ) equals [1  2 ] [1  2 ) equals [1  2 ) [1  2 ) equals (1   ) (1   ) equals [2  1 ] (1   ) equals [2  1 ) (1  1 ) equals (2  2 ) [1  2 ] before [1  2 ] [1  2 ) before [1  2 ) (1   ) before (1   ) [1  2 ] meets [1  2 ] [1  2 ) meets [1  2 ) (1   ) meets (1   ) [1  2 ] overlaps [1  2 ] [1  2 ) overlaps [1  2 ) (1   ) overlaps (1   ) [1  2 ] during [1  2 ] [1  2 ) during [1  2 ) (1   ) during (1   ) [1  2 ] starts [1  2 ] [1  2 ) starts [1  2 ) (1   ) starts (1   ) [1  2 ] finishes [1  2 ] [1  2 ) finishes [1  2 ) (1   ) finishes (1   )

Equivalencia 1 = 1   2 = 2 1 = 1   2 +  = 2 1 = 1 +    2 +  = 1 +  1 = 1   2 = 2 +  1 = 1   2 = 2 1 = 1 +    2 = 1 +  1 +  = 2   1 +  = 1 +  1 +  = 2   1 +  = 1 1 = 2   1 = 2 2 +   1 2  1 1 +   1 2 +  = 1 2 = 1 1 +  = 1 1  1   2  2   1 ≤ 2 1  1   2  2   1  2 1  1   1 +   1 +    1 ≤ 1 +  1  1   2  2 1  1   2  2 1  1   1 +   1 +  1 = 1   2  2 1 = 1   2  2 1 = 1      1  1   2 = 2 1  1   2 = 2 1  1   1 +  = 1 + 

Cuadro 5.13: Casos de relaciones entre períodos usando sus inicios y finales

incluye o no a 1 y a 2 , ó a 1 y a 1 + . Para quitar esta ambigüedad definamos que el uso de paréntesis [ ] indica ´  y el uso de los paréntesis ( ) indica exclusión, entonces tenemos las posibilidades de relacionar períodos de acuerdo a los casos mostrados en la tabla 5.13 (la letra griega  indica la granularidad de medición del tiempo y el subíndice  indica un intervalo).

5.9.

Tarea

Tomando como base las tablas TAR y ORDEN, construya los queries que permitan ilustrar cada una de las posibles relaciones entre parejas de ordenes de acuerdo a la tabla 5.13.

5.10. TABLAS DE ESTADO

49

Figura 5.1: Base de datos de empleados sin incluir manejo de tiempo.

Figura 5.2: Base de datos de empleados con el manejo de fechas de inicio y fin de la posición ocupada por el empleado

5.10.

Tablas de Estado

Una tabla temporal registra parte de la historia de una empresa, la información registrada en una tabla temporal tiene un tiempo a partir del cuál es valida y otro tiempo para el cuál dejo de ser valida, en este contexto, se requiere una columna para registrar el inicio de la validez de cada registro y otra columna para registrar el fin de la validez. En el caso concreto que la fecha de fin de validez no sea conocida se puede definir el valor como el máximo tiempo al que se tenga acceso, en el caso de oracle este es: December 31 4712 23:59:59. Asumamos que tenemos la base de datos para empleados ilustrada en la figura 5.1 Como podra verse la base de datos de la figura 5.1 no involucra el manejo del tiempo, más sin embargo es deseable llevar el historial de ocupaciones de los empleados por lo que será necesario agregar dos columnas, una para el inicio y otra para el fin de la ocupación según se ilustra en la figura 5.2. ¿Es correcto que la llave de la tabla Ocupación sea #Emp, #Pos? Obviamente es posible que un empleado tenga la misma posición en diferente tiempo, por lo cuál parecería que lo más razonable sería agregar como parte de

50

CAPÍTULO 5. TABLAS TEMPORALES #Emp 1 1

#Pos 17 17

Fecha Inicio 1996-01-01 1996-04-01

Fecha Fin 1996-06-01 1996-10-01

Cuadro 5.14: Tabla de ocupaciones ilustrando problemas en definir la llave primaria la llave la Fecha de Inicio, pero el contenido de la tabla 5.14 nos indica que el empleado podría tener traslapes en el tiempo donde tuviera la misma posición. El problema no se resuelve al agregar como parte de la llave la fecha de inicio, o la fecha de finalización o ambas. Requerimos la definición de una regla de integridad que refuerze que no tengamos traslapes de la misma posición. En este contexto definiendo como llave primaria (#Emp, #Pos, Fecha Inicio) y agregando un trigger (ORACLE) en el que se valide lo siguiente: CREATE TRIGGER validar AFTER INSERT or UPDATE on POSICION DECLARE valid INTEGER; BEGIN SELECT 1 INTO valid FROM DUAL WHERE NOT EXISTS ( SELECT I1.EMP# FROM OCUPACION I1 , OCUPACION I2 WHERE I1.EMP# = I2.EMP# AND I1.POS# = I2.POS# AND I1.FechaInicio  I2.FechaFin AND I2.FechaInicio  I1.FechaFin AND I1.ROWID != I2.ROWID ) AND NOT EXISTS( SELECT * FROM OCUPACION I1 WHERE I1.EMP# IS NULL OR I1.POS# IS NULL ); EXCEPTION WHEN NO_DATA_FOUND THEN RAISE_APPLICATION_ERROR ( -20001 ,’Error en llave primaria’) END;

5.11.

Tarea

Entregar un vídeo en el que se muestre la creación del Trigger en Oracle y se muestre su correcta operación.

5.12. TAREA

5.12.

51

Tarea

Asumiendo que al modelo de la base de datos de la figura 5.2 conteste a lo siguiente: 1. Cúal es la posición actual de Juan Perez (la variable current_date regresa la fecha-hora actual). 2. Cuáles empleados no tienen posición actualmente 3. Cuál era la posición de Pedro Lopez el primero de enero de 1999. 4. Los #Emp que han tenido exactamente la misma posición por mas de tres meses.

52

CAPÍTULO 5. TABLAS TEMPORALES

Capítulo 6

Visualización de Información 6.1.

Introducción

La ubicuidad de metáforas visuales para describir procesos cognoscitivos da idea de un nexo o relación entre lo que pensamos y lo que vemos. Por otro lado sin ayudas externas el pensamiento, la memoria y el razonamiento estarían altamente restringidas; el ser humano ha demostrado a través de la historia un increíble potencial para inventar ayudas externas que permitan el ”incremento” de sus habilidades cognoscitivas. Bajo esta línea de razonamiento podríamos concluir que las ayudas externas nos hacen más inteligentes. Las invenciones gráficas tienen dos propósitos fundamentales: a)Comunicar de una manera más fácil una idea (Confucio: Una imagen dice más que mil palabras); b) Permitir el descubrimiento de la idea, i.e. las invenciones gráficas permiten que la ”VISION PIENSE” y descubra patrones, relaciones, estructuras, agrupamientos, etc. que sería muy dificil descubrir viendo solo números o datos. Ahora, las invenciones gráficas tienen una historia antigua, lo que es realmente novedoso es la posibilidad de utilizar la computadora para poder crear representaciones gráficas de datos abstractos con bajo costo. A esta área de la ciencia se le conoce como VISUALIZACIÓN y en términos muy simples la visualización se divide en dos grandes bloques: Visualización Científica (Usada para representar datos provenientes de áreas como la física, la química, la meteorología, la astronomía, etc. donde normalmente está involucrado un fenómeno natural). Visualización de Información (Usada para representar datos provenientes de negocios, educación, etc. dónde existe siempre un proceso de abstracción para transformar los datos). 53

54

CAPÍTULO 6. VISUALIZACIÓN DE INFORMACIÓN

Figura 6.1: Gráfica usada para registrar fallas en los anillos del Challenger, indicando de acuerdo a lo negro lo grave de la falla y los números indican la temperatura ambiental del día de lanzamiento.

6.2.

Cognición Externa

Para darnos una idea del efecto que tiene el uso de ayudas externas para procesos cognoscitivos, pensemos en el tiempo que tomaría realizar una multiplicación de dos números cada uno de ellos con 4 cifras (v.g. 3467 × 6713) de las siguientes maneras: a)haciendo operaciones mentales; b)haciendo uso de lápiz y papel; c)haciendo uso de una regla de cálculo; y d)haciendo uso de una calculadora. Otro ejemplo representativo es el uso de cartas de navegación a través de las cuales ha sido posible realizar viajes por todo el mundo. Otra ayuda externa a los procesos cognoscitivos son los diagramas, por ejemplo la decisión de lanzar el Challenger en cierto día era tomada usando una ayuda gráfica similar a la ilustrada en la figura 6.1. En cada uno de los cohetes se indica la temperatura ambiental del día del lanzamiento y en caso de haber problemas en los anillos la cantidad de negro indica la gravedad de la falla. De acuerdo a esto era muy complicado ver la correlación existente entre temperaturas y la gravedad de una falla. En base a la manera propuesta por Tufte ilustrado en figura 6.2 representando gravedad de la falla versus temperatura la decisión de lanzar el Challenger un día con

6.3. VISUALIZACIÓN DE INFORMACIÓN

55

Gravedad de Falla

4

3

2

1

0 55

60

65

70

75

Temperatura

Figura 6.2: Gráfica de la gravedad de las fallas versus la temperatura ambiental del día de lanzamiento del Challenger. temperatura inferior a 65 ◦  no se hubiera tomado, dado que en todos los lanzamientos con temperaturas de 65 o menos hubo problemas algunos muy graves. En este contexto podemos decir que una ”mala” representación gráfica puede dar lugar a malas decisiones e incluso podría dar lugar a que se interprete algo totalmente contrario a los patrones o información inmersa en los datos originales.

6.3.

Visualización de Información

Con objeto de clarificar más el concepto de visualización de información introduciremos las siguientes definiciones: Cognición Externa. Es el uso del mundo externo para amplificar la cognición.

56

CAPÍTULO 6. VISUALIZACIÓN DE INFORMACIÓN Diseño de Información. Es el diseño de representaciones externas para amplificar la cognición. Gráficas de Datos. El uso de representaciones visuales de los datos para amplificar la cognición. Visualización. El uso de representaciones visuales e interactivas de datos basadas en computadora para amplificar la cognición. Visualización Científica. El uso de representaciones visuales interactivas de datos científicos, normalmente referidos a datos físicos, para amplificar la cognición. Visualización de información. El uso de representaciones visuales interactivas de datos abstractos normalmente ”no-físicos” para amplificar la cognición.

Los origenes de la visualización de información datan de 1786 cuando Playfair uso gráficas de datos, después en 1967 Bertin desarrollo una teoría sobre gráficas denominada: ”La Semiología de las Gráficas”, en 1983 Tufte desarrollo la idea de maximizar la densidad de información útil en una representación gráfica. Tanto Bertin como Tufte son reconocidos como los originadores del área de Visualización de Información. La primer conferencia sobre visualización del IEEE se llevó a cabo en 1990 y desde entonces se han publicado diversos esfuerzos relacionados con la construcción automática de representaciones visuales para poder procesar los grandes volúmenes de datos que son generados tanto en empresas como en el ámbito de investigación. Incluso han sido reportados esfuerzos por crear paradigmas usando Realidad Virtual para poder extraer de una manera cada vez más fácil patrones e información inmersa en datos abstractos. Solo para darnos una idea como una representación visual puede ayudar a descubrir estructuras, patrones e información faltante comentaremos el uso de la tabla periódica de elementos por parte de Mendeleyev para poder predecir elementos que aún no se conocían, pero que el derivó sus propiedades. En un caso más reciente Lucent Technologies está usando representaciones gráficas para detectar fraudes telefónicos.

6.4.

Amplificación Cognoscitiva

Larkin y Simon en 1987 condujeron un estudio sobre la solución de problemas de física usando diagramas y sin usar diagramas y concluyeron que tanto el tiempo como el esfuerzo para llegar a una solución se reduce significativamente al usar diagramas, debido principalmente por: a)Los diagramas permiten la agrupación de elementos y de esta manera reducen la necesidad de búsquedas innecesarias; b) Al asignar directamente a los objetos de un diagrama sus propiedades se reduce la necesidad de un apareamiento simbólico; c) los diagramas permiten percibir características de un problema que de otra manera sería más tardado.

6.5. MAPEO DE DATOS A UNA FORMA VISUAL

57

Figura 6.3: Pasos para el mapeo de datos a una forma visual. En general se puede decir que el uso de los diagramas es útil porque: 1. Incrementan la memoria y recursos disponibles por una persona. 2. Reducen la búsqueda de información. 3. Permiten la detección eficiente de patrones. 4. Habilitan operaciones de inferencia a través de la percepción. 5. Permiten el monitoreo de diversos eventos ilustrados en un diagrama. 6. Permiten la codificación (representación) de la información en una manera manejable.

6.5.

Mapeo de Datos a una Forma Visual

El proceso de mapeo de datos a una forma visual puede ser visto en el diagrama 6.3

6.5.1.

Tablas de Datos

La creación de tablas de datos, puede realizarse siguiendo una estructura similar a la mostrada en la tabla 6.1. Ejemplos de estas representaciones tabulares pueden ser encontradas en los modelos de bases de datos relacionales.

58

CAPÍTULO 6. VISUALIZACIÓN DE INFORMACIÓN Caso1

Caso2

...

Caso

Variable1 Variable2 ... Variable Cuadro 6.1: Forma típica para representar los datos en formato de tabla Tipos de Variables Los tres tipos básicos de variables son: N=Nominales (solo pueden ser iguales o diferentes a otros valores). O=Ordinales (obedecen a la relación , , etc.) C=Cuantitativas (se pueden realizar operaciones aritméticas con ellas). Las variables Cuantitativas pueden ser mapeadas a variables Ordinales a través de la división de sus posibles valores en rangos, v.g. la duración de una película podría considerarse: Pequeña, Normal. Larga de acuerdo a su duración en minutos (0-45), (46 - 90), (91-...). Ahora las variables Nominales pueden ser ordenadas de acuerdo a cierto criterio y establecer una relación de orden. Metadatos Los metadatos son información descriptiva acerca de los datos. De acuerdo a esta información se pueden crear representaciones con significado real, por ejemplo, especificando que una variable es Cuantitativa no es explícito el conjunto de valores válidos que puede tomar, por ejemplo si una variable cuantitativa indica número de nacimientos no sería correcto tener un número fraccionario, si una variable indica el número de horas de sol en un día en la tierra no sería correcta tener un valor de 30. Transformaciones de los datos La transformación de datos crudos (sin procesar) en tablas de datos para su visualización involucra con frecuencia la pérdida o ganancia de información. Incluso los datos originales pueden tener datos faltantes o con errores. Los tipos de transformaciones de datos básicos son: Valores → Valores Derivados Estructura → Estructura Derivada Valores → Estructura Derivada Estructura → Valores Derivados Ejemplos de estas transformaciones se ilustran en la tabla 6.2.

6.5. MAPEO DE DATOS A UNA FORMA VISUAL

Valor Estructura

Valor Derivado Media Calcular Varios Valores en Base a Una o Varias Columnas

59

Estructura Derivada Ordenamiento Derivar una Columna en Base a Una o Varias Columnas

Cuadro 6.2: Ejemplos de Transformaciones de Datos

Figura 6.4: Representación ”NO - EXPRESIVA” entre países y autos.

6.5.2.

Estructuras Visuales

Las tablas de datos son mapeadas a estructuras visuales que aumentan un sustrato espacial con propiedades gráficas para codificar información. Un mapeo se dice que es expresivo sii representa todo y solamente lo que está contenido en la tabla de datos (ni pérdida, ni ganancia). Una estructura visual no necesariamente es buena, por ejemplo la figura 6.4 introduce información Ordinal (de orden) entre los países siendo que solo se tiene información nominal (se puede deducir que EUA es más importante que Suecia, pero esto no está en los datos originales donde solo se da la relación nominal de la ”nacionalidad” de cada auto). Otro ejemplo de una representación no adecuada para deducir las estructuras internas de los datos es la representación con círculos de la figura 6.5 de los datos de la tabla 6.3 (Y=f(X)), la figura 6.6 es más expresiva y permite derivar la estructura interna de los datos.

60

CAPÍTULO 6. VISUALIZACIÓN DE INFORMACIÓN

Figura 6.5: Representación con circulos de los valores de una función.

y 1 0.8 0.6 0.4 0.2 0 -0.2

0

1

2

3

4

5

6

7

8

-0.4 -0.6 -0.8

x

-1

Figura 6.6: Gráfica de los datos de la función Y=f(X)

6.5. MAPEO DE DATOS A UNA FORMA VISUAL x 0 1 2 3 4 5 6 7 8

61

y 0 0.707 1 0.707 0 -0.707 -1 0.707 0

Cuadro 6.3: Datos Tabulares de una Función Percepción Una característica importante de una buena estructura de visualización es la facilidad con la que promueve la percepción humana. En este sentido es fundamental el estudio de la manera en la cuál el ser humano percibe visualmente la información para poder crear buenas estructuras visuales. Por ejemplo es importante el manejo de las distancias entre elementos visuales, los tamaños de los elementos visuales, los colores de cada elemento visual, las posiciones relativas entre los elementos visuales, el grado de agrupamiento entre elementos visuales, desvanecimiento de los elementos visuales, la similaridad entre los elementos visuales, etc. Sustrato Espacial No solo existen limitaciones en el sistema de percepción (ser humano), también hay limitaciones en el número de posibles representaciones que se pueden lograr a partir de los datos de una tabla. Los tipos de ejes que se pueden manejar en una representación son: Nominal, Ordinal y Cuantitativo (con interpretaciones similares a los tipos de datos). En este contexto una parte importante es la asignación adecuada de los tipos de ejes a cada uno de los elementos de la tabla de datos. Ahora con respecto a la colocación espacial de los ejes tenemos: Composición. Colocación ortogonal de los ejes creando una métrica 2D. Alineamiento. Es la repetición de un eje en diferentes posiciones del espacio. Doblado. Es la continuación de un eje en una dimensión ortogonal. Recursión. Es la repetida subdivisión del espacio. Sobrecarga. Es la reutilización del mismo espacio en más de una ocasión.

62

CAPÍTULO 6. VISUALIZACIÓN DE INFORMACIÓN

Extensión Diferenciación

Espacial Posición Tamaño Orientación

Objeto Escala de Grises Color Textura Forma

Cuadro 6.4: Propiedades Retinales Marcas Las marcas son los indicadores visibles que ocurren en el espacio. Hay cuatro tipos elementales de marcas: Puntos, Líneas, Áreas, Volúmenes. Conexión y Cerradura Las características de conectividad y cerradura adicionalmente transmiten mensajes importantes, por ejemplo en el caso de representaciones usando árboles y grafos, transmitimos mensajes relativos a la estructura interna de los datos. En el caso de cerradura (un objeto cerrado) se transmite la idea de agrupamiento o contenedor. Propiedades Retinales Las propiedades retinales deben ser consideradas para la creación de estructuras visuales. En general tenemos propiedades relacionadas con la extensión y la diferenciación de los objetos y el espacio, esto es ilustrado en la tabla 6.4. Codificación Temporal Una manera de codificar el tiempo en una representación visual es a través de la animación.

6.5.3.

Transformaciones de Vistas

Las transformaciones visuales permiten la transformación de una representación estática en una VISUALIZACIÓN. Algunas transformaciones de vistas son: Localización de Sonda. Control de Puntos de Vista Distorsiones. Localización de Sonda Permite el introducirse en la estructura interna de una representación para observarla internamente, por ejemplo el poder entrar a un sólido y observarlo internamente.

6.6. OBJETIVO FINAL DE LA VISUALIZACIÓN DE INFORMACIÓN

63

Control de Puntos de Vista Se refiere al poder realizar: ZoomIn, ZoomOut, Paneo, etc. De este modo se pueden visualizar y resaltar detalles importantes. Distorsiones Son transformaciones visuales que permiten el magnificar y empequeñecer simultáneamente algunos elementos visuales. Tómese como ejemplo la distorsión que se observa en ciertos espejos en los que los elementos cercanos se distorsionan y se ven más grandes de lo que realmente son al mismo tiempo que los elementos lejanos se distorsionan y se ven más pequeños de lo que realmente son.

6.5.4.

Interacción Humana

El humano puede interactuar con la visualización para hacerla más expresiva, por ejemplo el puede realizar el movimiento de elementos visuales. Por ejemplo el podría ”estirar” los enlaces de un grafo o mover los nodos a otra posición. La interacción del humano también puede permitir el ajuste de los posibles mapeos ilustrados en la figura 6.3.

6.6.

Objetivo Final de la Visualización de Información

Podemos concluir con dos posibles objetivos de la visualización de información. Permitir que la visión piense. La creación de ayudas externas que proporcionen maneras de representar una idea y/o datos en un medio externo de manera tal que se pueda mantener y manipular más allá de las limitaciones que tiene un humano en su ”memoria de trabajo”.

Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.

Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.

Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.

Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.

Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.

Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.

Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.

Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.

Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.

Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.

Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.

Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.

Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.