aproximación metodologíca de un spatial data warehouse

manejadores de bases de datos (DBMS), como Oracle, DB2, SQL Server, Informix o. Sysbase, con un conjunto de herramientas auxiliares en algunos casos ...
716KB Größe 11 Downloads 155 vistas
1

APROXIMACIÓN METODOLOGÍCA DE UN SPATIAL DATA WAREHOUSE

Juan Eulises Bohorquez Especialista en SIG. Ingeniero Desarrollador Oracle DBA.

2

RESUMEN APROXIMACIÓN METODOLOGÍCA DE UN SPATIAL DATA WAREHOUSE Los Spatial Data Warehouse, son una gran base de datos por decirlo de una manera sencilla, que habilita espacial e históricamente la información del negocio, desde una perspectiva holística orientada a las áreas del negocio no a las aplicaciones transaccionales del día a día, para servir de sustento en la toma de decisiones; el Spatial Data Warehouse puede almacenar básicamente el contexto espacial del dato desde dos perspectivas muy diferentes, la primera es la manipulación del mismo como un dato agregado y la segunda como una variable principal de acceso y análisis de la bodega; dependiendo la connotación se define el modelo de la bodega, para el primer caso se puede definir un modelo multidimensional puro, pero para el segundo es imprescindible utilizar un modelo híbrido entre un modelo multidimensio nal y uno objeto relacional, debido a que la manipulación de la geografía del dato se debe desarrollar en el marco de la tecnología orienta a objetos, para no tener limitantes en los análisis tradicionales de la bodega; El Spatial Data Warehouse no es sola mente la bodega en si, si no todo el conjunto de herramientas y procedimientos desde el poblado de la misma a partir de los sistemas transaccionales actuales, la transformación y estandarización de todos lo datos, la fijación del valor temporal del dato, la habilitación espacial de los mismos, asi como toda la infraestructura para consulta, el análisis en línea y el análisis detallado de tendencias por técnicas de minería de datos, que se desarrollan sobre la bodega para poder tomar las decisiones pertinentes del negocio. La construcción de una metodología no se simplifica a la consecución de tareas y procesos de lo que se debe hacer, si no el marco conceptual de la implicación de este tipo de proyectos para que sean un completo éxito, ya que la idea es dar los lineamientos fundamentales para que la metodología se desarrollo basado en el negocio mismo no en una receta de cocina, recordemos que el 50% de proyectos Data Warehouse en el mundo han sido un completo fracaso por esta y otras causas; y si le sumamos la falta de cultura cartográfica en el negocio, será el fracaso de los proyectos Spatial Data Warehouse.

3

1. INTRODUCCIÓN APROXIMACIÓN METODOLOGÍCA DE UN SPATIAL DATA WAREHOUSE Los sistemas de bases de datos han significado y representado una gran herramienta en la administración y gerencia de la información, han evolucionado a tal punto que han dejado de ser unos simples reservorios y repositorios de datos alfanuméricos estáticos para convertirse en la estructura ideal para almacenar cualquier tipo abstracto de dato que tecnológicamente se pueda automatizar y digitalizar, ya sea de manera estática, dinámica o inteligente.

En la actualidad los motores de administración de bases de datos, son herramientas de software muy sofisticadas que han ocultado al usua rio la complejidad de sus algoritmos potencializando la utilización de las mismas, de tal manera que la implementación del sistema de información sea una tarea sencilla, dedicando el esfuerzo y la importancia del proyecto a la etapa de diseño del mismo.

Teniendo en cuenta las premisas anteriormente mencionadas, los sistemas de información deben dejar de ser estructuras estáticas de procesamiento, almacenamiento y análisis de la información; para convertirse en robustas bases de datos que integren y analicen toda la globalidad del negocio, teniendo en cuenta los datos alfanuméricos que representan comportamientos del negocio sin olvidar la espacialidad de los mismos, pero no como una simple colección y posterior almacenamiento de datos, si no como una estruc tura holística dinámica, variante en el tiempo y con comportamientos propios. Diseñando un nivel superior en las bases de datos conocido como las bodegas de datos con componente geográfico o Spatial Data Warehouse.

4

2. FUNDAMENTOS DE SPATIAL DATA WAREHOUSE

2.1.

PANORAMA DEL SPATIAL DATA WAREHOUSE

Orientado a

Integrada

temas Variante en

Ge og ráf ica

Un Spatial Data Warehouse es una colección de datos orientados a temas, integrada, variante en el tiempo, no volátil, que añade la geografía del dato, en la base de análisis, para el apoyo a la toma de decisiones.

No Volatil

El tiempo

Fig. No.1

Esquema de definición del Spatial Data Warehouse

Un simple, completo, y consistente almacenamiento de datos, obtenidos de una variedad de fuentes, con el fin de estar disponibles para usuarios finales en caminados a entender y manipular el contexto del negocio 1 .

Fig., No. 2 Ámbito operacional del Data Warehouse

Un Data Warehouse es una base de datos que:

1

-

Es organizada como servidor central de almacenamiento de los datos.

-

Es usada para ingeniería de datos (Data Mining), y otras aplicaciones.

-

Reúne un especifico juego de requerimientos del negocio.

-

Usa los datos que agrupan un predefinido juego de criterios del negocio 2 .

Barry Devlin, “Data Warehouse from Architecture to Implementation”

5

Simplemente puede ser una gran base de datos que sostiene copias o agregaciones de datos desde otros sistemas y que poseen alta disponibilidad para ser usadas por otras aplicaciones.

2.1.1. ORIENTADO A TEMAS Los datos son categorizados y almacenados por temas del negocio y no por aplicación, es decir que la información es organizada, almacenada, y analizada por áreas temá ticas y no análisis específicos que resumen o colectan información especifica de distintos segmentos del negocio para cumplir con un fin único y especifico, consolidado en una aplicación estática; por cada tema del negocio se puede mirar un abstrac de los datos que permitan concluir en un intervalo de tiempo para ciertas variables cual es el comportamiento global del negocio. En una aplicación la información en la base de datos se tiene organizada de tal manera que se pueda extraer de forma directa, es decir que por aplicaciones se diseñan e implementan bases de datos, a diferencia en un Data Warehouse, donde se tiene una sola base de datos diseñada, estructurada y organizada por áreas temáticas, independiente a las diferentes aplicaciones que necesiten extraer información de la misma; la ventaja de tener base de datos por aplicación radica en la alta accesibilidad a los datos, lo que implica un alto desempeño y velocidad en los análisis ya que los mismos ya están preestablecidos, mientras que en el Data Warehouse para satisfacer con esta ventaja se requiere que la información este desnormalizada, es decir con redundancia, duplicidad de los datos y que la información este dimensionada para evitar que el motor de consultas tenga que recorrer toda la base de datos para encontrar lo que necesita, si no que simplemente la consulta sea enfocada por vectores o variables que permitan localizar los datos de manera rápida y eficaz, para satisfacer una alta demanda de análisis complejos en un mínimo tiempo de respuesta.

2

Rob Mattison, “Data Warehousing Strategies, Technologies , and Techniques”

6

2.1.2. INTEGRADO Los datos son almacenados una sola vez de acuerdo al área temática a la que pertenecen, como en el ámbito del Data Warehouse no se realiza el diseño de acuerdo a las aplicaciones si no a las áreas del negocio, los datos son integrados y estructurados como un solo ente en la organización; manipular la información de esta manera nos permite garantizar un juego de información estándar, consistente, exacto, consolidado, y confiable para todas las aplicaciones, procesos y análisis del negocio.

La integración implica que todos los datos de diversos sistemas transaccionales (OLPT), que son producidos por distintas secciones y distintas aplicaciones, deben ser unidos en una instancia antes de ser agregados al Data Warehouse, este proceso se conoce como el Proceso de Extracción, Transformación y Transporte de los datos.

2.1.3. VARIABLE EN EL TIEMPO Una de las principales ventajas del Data Warehouse, es que los datos son almacenados con sus respectivos históricos, lo que garantiza poder desarrollar análisis de la dinámica de los mismos, pues ellos son almacenados como una serie de instantáneas, cada uno representando un periodo de tiempo; es importante tener en cuenta la granularidad de los datos, así como la dinámica de cambio natural del comportamiento de los fenómenos del negocio para evitar crecimientos incontrolables y desbordamientos de la base de datos, el intervalo de tiempo y periodicidad de los datos se define de acuerdo a las necesidad y requerimientos de los usuarios confrontados con la realidad de las fuentes de los datos, por ejemplo los usuarios desean saber el margen de venta de cada quince minutos del mes pasado, pero los totales de venta se desarrollan diarios. Toda la información en el Data Warehouse posee su propio sello de tiempo.

El almacenar los datos de manera histórica, es lo que le permite al Data Warehouse desarrollar pronósticos y análisis de tendencias y patrones, a partir de una base estadística

7

de información, ya que las instantáneas son refrescadas de acuerdo con las actividades del negocio.

Fig. No. 3 Sello de tiempo del Data Warehouse

2.1.4. NO VOLATIL Típicamente los datos del Data Warehouse no son actualizados desde los sistemas operacionales, los nuevos datos son insertados como nuevos registros, en ningún momento se sobrescriben los existentes, las manipulaciones de los datos se simplifican a un cargue masivo inicial de todos los datos base, inserción de los cambios y nuevos datos, de acuerdo al ciclo de refresque, y acceso de los datos por los usuarios para análisis; en un Data Warehouse no hay borrado, ni actualización de registros, solamente consulta e inserción.

Fig. No. 4 Esquema de operaciones DML en el DWH

8

2.1.5. GEOGRAFIA DEL DATO Un modelo de datos Geográfico es una abstracción del mundo real que emplea un conjunto de objetos dato, para soportar el despliegue de mapas, consulta, edición y análisis. Los datos Geográficos, presentan la información en representaciones subjetivas a través de mapas y símbolos, que representan la geografía como formas geométricas, redes, superficies, ubicaciones e imágenes, a los cuales se les asignan sus respectivos atributos que los definen y describen.

El Spatial Data Warehouse forma el corazón de un extensivo Sistema de Información Geográfica para la toma de decisiones, el Spatial Data Warehouse al igual que los SIG, permiten que un vasto numero de usuarios accedan a información integrada, a diferencia de un simple Data Warehouse que es orientado a temas, el Spatial Data Warehouse adicionalmente es geo - relacio nal, es decir que en estructuras relacionales combina e integra los datos espaciales con datos descriptivos, en la actualidad es Geo – Objetos, es decir que los elementos geográficos se manifiestan como objetos con todas sus propiedades y comportamientos; adicionalmente están almacenados en una única base de datos objeto – relacional.

El Spatial Data Warehouse, no es mas que un Data Warehouse con componente geográfica, no como un dato agregado, sino como una dimensión o variable en la tecnología de la información, de tal manera que permita modelar todo el negocio como un ente holístico, y que a través de herramientas de procesamiento analítico en línea (OLAP), no solamente se posea un alto desempeño en consultas multidimensionales si no que adicionalmente se puedan visualizar y analizar espacialmente los resultados.

Los Spatial Data Warehouse, son aplicaciones basadas en un alto desempeño de las bases de datos, que utilizan arquitecturas cliente / servidor para integrar diversos datos en tiempo real, mientras los Data Warehouse trabajan con muchos tipos y dimensiones de datos,

9

muchos de los cuales no referencian ubicación espacial, a pesar de poseerla intrínsecamente, y sabiendo que un 80 % de los datos poseen representación y ubicación en el espacio, en los Spatial Data Warehouse, la variable geográfica desempeña un papel importante en la base de información para la construcción del análisis, y de igual manera que para un Data Warehouse, la variable tiempo es imprescindible en los análisis, para los Spatial Data Warehouse la variable geográfica debe ser almacenada directamente en la bodega de datos.

Datos en el Spatial Data Warehouse ID 100 101 102 103

Datos

Tiempo Tiempo

Geometria

104 104 105

Fig. No. 5

Esquema de los datos en el Spatial Data Warehouse

La implementación de los diferentes Spatial Data Warehouse varia, basados en primer lugar en las herramientas que se utilizan y seguido de los modelos que se empleen, el diseño y fundamentos permanecen constantes, a nivel de implementación la única consideración a nivel de software y hardware que se debe tener en cuenta es que este tipo de proyectos demandan grandes recursos operativos y administrativos, tales como grandes y robustos manejadores de bases de datos (DBMS), como Oracle, DB2, SQL Server, Informix o Sysbase, con un conjunto de herramientas auxiliares en algunos casos complejas, y de igual manera herramientas profesionales de SIG, como ArcSDE, ArcInfo entre otras; y sin olvidar una gran infraestructura de hardware; pero como mencionábamos en cualquier proyecto informatico la conceptualización y el diseño son independientes a la implementación, considerando un esquema general del diseño proyecto la figura 14.

10

Metodologia Diseño y Modelamiento ETT

Geográfia

Administración

Acceso y Analisis

De los datos

de los Datos

de los Datos

Fig. No. 6

Esquema general del diseño proyecto Spatial Data Warehouse

Sin importar lo diferente o complejo que sea el proyecto Spatial Data Warehouse los siguientes pasos se ma ntienen en el diseño: •

Implementación de Metodologías.



Consideraciones de diseño y modelamiento.



Georeferenciación y geocodificación de la información espacializable.



Desarrollo de procesos y aplicaciones para el accesos y análisis de los datos.



Consideraciones de Administración, seguridad y afinamiento de los datos.



Estandarización y automatización de los procesos de extracción, transformación y transporte de los datos (ETT).

El pilar del proyecto de Spatial Data Warehouse esta en la metodología a seguir, pues ella asegura el éxito o el fracaso del proyecto, al diseñar la metodología a utilizar se debe garantizar que sea de desarrollo incremental, es decir que permita crecer con nuestras nuevas expectativas y que cumpla cabalmente con los alcances trazados para el proyecto, y lo mas importante que sea segura y confiable; la metodología que se va a postular en este documento es un híbrido entre las metodologías de Data Warehouse tradicionales y las metodologías de proyectos de Sistemas de Información Geográfica, en un marco objeto relacional. Un agente que toma importancia en el proyecto SDWH, es la manera como desarrollemos el modelamiento, lo que tradicionalmente conocemos en proyectos SIG, como la etapa de la conceptualización; todos aquellos análisis de requerimientos y expectativas a cubrir a lo largo del proyecto; la determinación de estructuras operativas,

11

áreas de orientación, identificación de flujos operativos y administrativos de los datos, definición de agentes involucrados, relaciones entre los mismos; identificación de temas, categorías, jerarquías y atributos de los datos; el modelamiento debe ser interactivo y en el mismo es recomendable incluir todas aquellas personas que conozcan y sean participes en las actividades operacionales del negocio, sin olvidar que la bodega es orientada a temas y no a funciones o aplicaciones.

El proyecto puede iniciar con la empresa, pero esto muy raras veces ocurre, porque cuando una empresa u organización, se inicia en el negocio muy pocas veces nace moderadamente mediana o grande, lo cual no justifica la inversión en proyectos de esta índole, en la mayoría de situaciones la empresa a la cual nos enfrentamos tiene información ya preestablecida y una infraestructura plenamente definida; lo cual implica una definición para desarrollar toda una tarea para evaluar los procesos actuales de producción y manipulación de los datos, revisar las bases de datos transaccionales y todos los procesos transaccionales en línea, no es recomendable imponer nuevos procesos que modifiquen significativamente las condiciones actuales de producción del negocio, ya que causan indisposiciones en el personal activo de la empresa, y algo a tener muy en cuenta en los proyectos Spatial Data Warehouse es la completa colaboración y disposición de las personas involucradas directa e indirectamente en el proyecto para que este sea un éxito; otra causa es que la compañía no puede dejar de producir o esperar a que el proyecto este funcionando para seguir operando, lo que implica que su desarrollo es paralelo a toda la organización del negocio; en síntesis el procedimiento a seguir una vez se tenga todo el diseño y modelamiento listo, es construir todo un proceso de extracción de datos de las bases de datos transaccionales, de las fuentes y destinos mismos, desarrollar su respectiva validación, estandarización, limpieza, integración y lo mas importante ponerle su sello de tiempo, todo esto en un proceso de transformación; y finalmente transportarlo hasta la bodega transitoria de almacenamiento, solamente la información que no posea o deba tener componente geográfica puede pasar directamente a la bodega de datos definitivos, seguidamente se debe desarrollar todo un proceso de evaluación de la información de la bodega transitoria dentro de un contexto geográfico; dentro del Spatial Data Warehouse la

12

información geográfica puede tener dos connotaciones muy distintas, la primera es ser un dato agregado o de referencia, es decir que durante todo los procesos y operaciones de la empresa es estático, por ejemplo la sectorización local de una ciudad (localidad, sector, barrio), sabemos que su dinámica de cambio es mínima, y en algunos casos no depende de nosotros; la segunda es que sea una variable o un dato producido en los procesos del negocio, y que su dinámica de cambio dependa de la dinámica del negocio, por ejemplo la distribución domiciliaria diaria de nuestros productos, la traza sísmica elaborada durante el mes para prospección geofísica, etc. La tarea de este punto en consideración consiste en georeferenciar y geocodificar la información mapificable, para lo cual nos ayudamos de cartografía digital base, y de herramientas tipo SIG, es decir que manipulen y estructuren la información topologicamente; si la información existe en nuestra división de sistemas, la tarea consistirá en procesarla como un dato normal, es decir sufre un proceso ETT normal, si no existe habrá que construirla o adquirirla, y disponer de toda una nueva infraestructura en este campo para mantenerla, procesarla y analizarla. Todos estos procedimientos no son iniciales, se presentan y desarrollan durante todo el ciclo de vida del Spatial Data Warehouse, y se presentan de acuerdo al ciclo de refresque de la bodega, por ello es debido desarrollar aplicaciones y procesos en lotes para automa tizar todas estas tareas y que sean ejecutadas periódicamente o programados en una agenda digital computacional. Todos los procesos y en especial el ETT, debe estar acompañado de una administración responsable, robusta y en un ambiente seguro para evitar corrupción o violación en los datos, ya que son la materia prima y mas valiosa de nuestra bodega, el ambiente de seguridad y administración debe existir del lado de alimentación de la bodega como del lado de usuarios y accesos a la misma.

13

Fig. No. .7. Procesamiento Transaccional en línea Soporta las operaciones diarias de la compañía

Ambiente de la Bodega

BD OLTP 010101010101010101 010101010101010101 010101010101010101 010101010101010101

Archivos Planos

Base de Datos Integradora (bodega transitoria)

Cartografia Existente

Plataforma de Producción

Spatial Data Warehouse

Fig. No. 8

Proceso de Extracción, Transformación y Transporte de los datos para alimentar la bodega.

En el proyecto uno de los esquemas mas importantes es el de acceso a la bodega, ya que la finalidad del Spatial Data Warehouse no es simplemente almacenar todos los datos del

14

negocio por áreas, sino la esencia es servir de base para la inferencia y construcción de información que sustente la toma de decisiones; en la mayoría de textos tradicionales de bases de datos el termino dato es permutable y equivalente al termino información, pero la diferencia es sencilla, pongamos dos ejemplos que permiten definir y diseminar claramente los dos términos, primero se realiza una consulta al repositorio de datos ¿ Cuanto vendí la semana pasada y en donde?; y la segunda ¿Qué combinación de productos se vendieron mejor la semana pasada y como están segmentados a lo largo de la ciudad ?, la diferencia es clara en el primer caso es una simple consulta a un dato en la bodega, y la segunda extrae información de la misma, combinando en línea distintas variables que determinan el comportamiento del negocio, mas adelante hablaremos en detalle de este tipo de consultas que son extraídas con herramientas de procesamiento analítico en línea (OLAP). Una vez claro los conceptos información y dato, se necesitan un conjunto de herramientas como ya mencionamos que permitan la extracción de información y la construcción de reportes a partir de los datos en la bodega, estas herramientas deben ser fáciles de usar, intuitivas, deben permitir que los usuarios naveguen libremente de lo general a lo particular en los datos, así como permitir documentar los mismos y de fácil capacitación para uso masivo, pero recordemos siempre en un ámbito de seguridad y administración estable; se debe establecer previo a la implementación las dimensiones de los alcances de los requerimientos de los usuarios, ya sea para adquirir las herramientas que cumplan cabalmente con los requisitos, construirlas, o simplemente personalizar las adquiridas o existentes, adicionalmente se debe tener en cuenta que la bodega de datos no es cualquier base de datos, que su tamaño en muy superior, que la estructura de los datos no es común, y que la información geográfica no es tabular y que por ende requerimos herramientas tipo SIG, para que consulten la bodega, visualicen, manipulen y analicen los datos espaciales en un ambiente topológico, y en esquema cliente / servidor, como lo es el Spatial Data Warehouse, donde el servidor central mantiene los datos, la administración y la seguridad, el cliente inicia una transacción con el, realiza una petición de los datos, y una vez el servidor haya autorizado la transacción y respondido la petición el cliente los analice, interprete y procese.

15

Ambiente operacional de la Empresa

Ambiente de la Bodega

Ambiente de la Bodega

BD OLTP 010101010101010101 010101010101010101 010101010101010101 010101010101010101

Archivos Planos

Base de Datos Integradora (bodega transitoria)

Cartografia Existente

Plataforma de Producción

Usuarios Plataforma de Producción

Spatial Data Warehouse

Simples

Previsivas

OLAP

Consultas

Fig. No. 9

Esquema General de alimentación y consultas del Spatial Data Warehouse

Este tipo de proyectos, son costosos porque no solamente se cuantifica recursos logísticos, operativos, desarrollos y adquisición de herramientas especializadas; también se necesita una correcta infraestructura que cumpla con lo idealizado, los recursos que consume el Spatial Data Warehouse no solamente son de software, un gran recurso es dedicado al hardware; el calculo de los volúmenes de datos y su crecimiento debe desarrollarse con calma y lo mas acertado posible, para prever costos, así como para desarrollar los afinamientos requeridos, para que el sistema no sufra saturaciones ni caídas, si las respuestas del servidor a las peticiones de los usuarios son lentas, nadie lo a terminar usando o va a ser un dolor de cabeza para el administrador de la bodega, preveer todo esto para la configuración del servidor, hoy en día existen muchas tecnologías para suplir estas necesidades, como paralelismo, arreglos de disco, indexamiento, tablas particiónadas, etc. De ello depende el optimo desempeño y disponibilidad del sistema.

16

2.2.

ESQUEMA DEL SPATIAL DATA WAREHOUSE

Vamos a entrar mas en detalle en todas los componentes que hacen parte del Spatial Data Warehouse, hasta el momento el esquema se ha simplificado a mirarlo desde dos perspectivas muy sencillas, la primera del lado de la alimentación y la segunda del lado de las consultas de la bodega. En un Spatial Data Warehouse, cuando nuestras fuentes de datos son muy variadas y requieren de muchos tratamientos es recomendable definir toda una infraestructura para nuestra base de datos integradora, a la cual desde ahora vamos a denominar Almacén de Datos Operacionales (Operational Data Store ODS), pero porque hasta ahora esa denominación?, o es que el ODS y la base de datos transitoria es lo mismo?, son dos preguntas que nos podemos cuestionar; el ODS es mas que una base de datos transitoria donde simplemente, limpiamos, unificamos, integramos, y organizamos datos; simplemente esto es lo que se desarrollaría en una base de datos transitoria, adicionalmente la tareas de los ODS, es estructurar y soportar todos los datos de análisis, organizar los datos por áreas para la bodega, realizar las sumarizaciones de los datos, pero porque sumarizaciones?, si en las consultas se pueden desarrollar?, en la bodega se debe preestablecer los totales mas requeridos y de igual manera los mas complejos y pesados, debido a que en primera instancia algunos implican un predicado muy complejo, lo cual no es operable para los usuarios finales, de tal manera que se debe esconder toda la complejidad en las consultas, que simplemente sea ingeniería del mouse; en segunda instancia las sumas para obtener totales consumen mucho recurso del servidor (SGA, PGA) de tal manera que satura el servidor, el desempeño y velocidad se ven sacrificados, por ello a nivel del ODS, se deben prever que sumarizaciones deben estar desarrolladas; de igual manera en el ODS se dimensionan los datos geográficos y se desarrollan los análisis preliminares que el cliente no debe hacer con respecto a la espacialidad del dato, tales como cruces topológicos y relaciones complejas y de igual manera las sumarizaciones debe quedar en la bodega disponibles para los mismos; los ODS pueden estar sincronizados con los sistemas OLTP, y por ende se pueden desarrollar sobre el mismo análisis en tiempo real, que no impliquen grandes dimensiones en el tiempo, ya que la finalidad del ODS, no

17

es guardar el histórico del dato, si no simplemente es una área de organización para la bodega y no desempeña las tareas de la bodega, o una instantánea de la bodega en un momento dado.

ODS

OLTP Analistas del Negocio

SDWH

Fig. No. 10

Panorama del ODS

En la búsqueda del afinamiento optimo de la bodega, es recomendable manejar una nueva estructura

de organización y administración de la información, está no a nivel de

estructuración de los datos, ya que está es la tarea de los ODS; la finalidad es a nivel de descongestión de la bodega, se debe tener en cuenta de acuerdo a las peticiones del servidor, de tal manera que muchas de las consultas sean canalizadas a otro servidor de la bodega, no necesariamente un servidor espejo, ya que los costos serian innecesarios pues el desempeño no se incrementa lo deseable, como si realizáramos uno o varios subconjuntos de la bodega, por decirlo así un punto de distribución por sector, en términos del Spatial Data Warehouse, se denominara supermercado de datos (Data Mart), los Data Mart pueden ser construidos y definidos de acuerdo a la localización de los usuarios o por lo general por departamentos; como hemos mencionado la finalidad de los Data Mart es reducir la demanda de la bodega, reducir el trafico de la red, y en algunos casos por estrategia operativa, debido a su finalidad la construcción de los mismos se puede desarrollar en servidores no tan robustos como el de la bodega; operativamente se establecen

18

encadenadores entre la bodega y el Data Mart, se crean instantáneas de los datos y se les asigna un tiempo de refresque o sincrónicamente con la bodega.

ODS

OLTP SDWH

Data Marts

Fig. No. 11

Esquema de los Data Marts

Los Data Mart pueden ser de dos tipos de acuerdo a la operaciones que se desee desarrollar con los mismos, los primeros son los dependientes que son los que hemos venido describiendo, son segmentos parciales de la bodega, son construidos y cargados a partir de la misma, y los Data Mart independientes, los cuales son construidos e implementados a partir de los procesos ETT, o de los ODS directamente, estos últimos son implementados en algunos casos sin existir la bodega, se desarrolla así por cuestión de costos y porque el Data Mart posee todas las características mencionadas de la bodega, en algunos casos se desarrollan los proyectos Spatial Data Warehouse construyendo una serie de Data Mart por departamentos con costos increméntales diferidos, una vez se han construido todos los Data Mart se procede a implementar la bodega; cuando los datos geográficos son demasiados complejos es recomendable diseñar Data Mart específicamente para manipular estos datos, siendo los mismos dependientes preferiblemente, pero si los datos geográficos son estáticos

19

y específicos por departamento es recomendable desarrollar un híbrido entre los dependientes e independientes, siendo los datos agregados cargados directamente a los Data Mart por procesos ETT, o simplemente completamente independientes.

OLTP

SDWH Data Mart

Fig. No. 12

Data Mart dependiente

OLTP Data Mart

Fig. No. 13

Data Mart independiente

OLTP

SDWH

Data Mart Data Mart híbrido

Fig. No. 14

20

La componente mas poderosa de los Spatial Data Warehouse, heredada de los Data Warehouse, el procesamiento analítico en línea OLAP, es el motor de consultas especializadas de la bodega, las herramientas OLAP son una tecnología de software para análisis en línea, administración y ejecución de consultas complejas que permitan inferir información del comportamiento del negocio, las herramientas OLAP son implementadas en arquitecturas cliente servidor y su finalidad es brindar rápidas respuestas a múltiples consultas, la fortaleza de los OLAP es poder brindar escenarios históricos de cómo se a venido comportando el negocio en un ambiente multidimensional, es decir combinando múltiples

variables

simultáneamente,

desarrollando

su

análisis

desde

diferentes

perspectivas que aparentemente no se relacionen para poder inferir tendencias que a simple vista no se encontrarían fácilmente; las herramientas OLAP requieren que los datos estén organizados dentro de la bodega de forma multidimensional, lo que implica el modelamiento basado en los principios de las bases de datos multidimensionales o emulaciones de la misma; una base de datos multidimensional es aquella que organizan los datos por dimensiones por ejemplo el producto x se vende en t tiempo, en s lugares, la base de datos estructura para este caso tres dimensiones x, t, s formando un cubo donde el cruce de los valores x, t, s a lo largo de las abscisas determinan el valor del dato, el hecho de que ocurrió una venta, lo que implica que los mismos son extraídos y representados por dimensiones de cualquier orden y multiplicidad, los cálculos sobre la misma son matriciales los cuales se procesan rápidamente dando como resultados reportes tabulares; las bases de datos multidimensionales implican un modelamiento estrella, copo de nieve, o constelación los cuales explicaremos mas en detalle posteriormente, los cuales pueden ser implementados de manera relacional, multidimensional o un híbrido entre los dos, dependiendo toma la denominación de ROLAP (relacional), MOLAP (multidimensional) o HOLAP (híbrido); independiente a la arquitectura este tipo de modelamientos requieren que todo el modelo este desnormalizado o semi desnormalizado para efecto de no desarrollar complejas uniones para acceder a los datos, ocultar y agilizar la complejidad de las consultas, en el caso de que los datos espaciales no sean datos agregados si no dimensiones de la información es imprescindible desarrollar modelos híbridos, empleando geo_objetos dentro de un contexto objeto_relacional híbrido con el multidimensional

21

(HOLAP), para poder desarrollar el análisis en línea de lo contrario no seria posible implementar la dimensión espacial, en caso de que el dato espacial sea un dato agregado y que no sea considerado como una dimensión dentro de la bodega, se puede estructurar como un atributo tipo comentario o detalle estático dentro de una dimensión auxiliar. En muchas ocasiones la utilizaciones de herramientas OLAP usadas de manera masiva sobre la bodega saturan la red, lo que nos obliga a direccionarlas a Data Mart, o implementar servidores OLAP que descongestionen las peticiones al servidor.

OLTP

SDWH OLAP

Fig. No. 15

On-line Analytical Processing OLAP

OLTP

SDWH Servidores OLAP

Fig. No. 16

Servidores OLAP

Las bases de datos multidimensionales (tecnología OLAP), proveen una estructura de datos que permite un flexible acceso a los datos, y explorar las relaciones entre la sumatoria y el detalle del dato. Usted puede visualizar el modelo multidimensional como por ejemplo un cubo en donde las variables asociadas con valores existen a lo largo de los tres ejes, en algunos casos son mas de tres dimensiones, el poder de este modelo radica en el alto grado

22

de análisis para combinar en línea las diferentes variables para extraer información, el diseño del mismo se puede desarrollar a partir de un modelo relacional desarrollando las respectivas transformaciones, o de manera inmediata al dimensional, la estructura del mismo radica en dimensiones que son definidas por el usuario las cuales son variables de acceso a los datos o simplemente son los mecanismos para disgregar las medidas de la organización; y una tabla de hechos que plasma la ocurrencia de una acción a lo largo de las dimensiones, los hechos son el corazón del Spatial Data Warehouse, se compone de todas las llaves de las dimensiones indicando la existencia de un dato definido por las dimensiones, los resultados de los análisis son representados por cruces de matrices de

Ub ica ció n

acuerdo a las dimensiones accedidas.

Tiempo

Producto Fig. No. 17 Base de datos multidimensional

Otra componente de los Spatial Data Warehouse es la ingeniería del dato (Data Mining), la cual es la herramienta que permite inferir comportamientos, modelos, relaciones y estimaciones de los datos, para poder desarrollar predicciones de los mismos, sin prescindir de algún patrón o regla preestablecida o conocida, el Data Mining básicamente es una técnica de descubrir patrones y relaciones entre los datos que a simple vista no se puedan inferir, las consultas de Data Mining pueden tardar de minutos a horas dependiendo el

23

volumen de datos que se le especifique a recorrer, las herramientas que se utilizan o construyen para Data Mining están basadas en inteligencia artificial, sistemas expertos, algoritmos genéticos y árboles de probabilidad, entre otras muchas mas. Un ejemplo de una consulta de Data Mining es ¿Qué productos se venden mejor a que hora del día y en donde?, y una respuesta supuesta podría ser, la cerveza en lata se vende mejor si se encuentra cerca de los pañales desechables, el fin de semana en los almacenes que se encuentran localizados cerca de zonas residenciales de apartamentos, de estrato 4. El diseño e implementación de estos sistemas son de cuidado, de un arduo desarrollo y programación de alto nivel, motivo por el cual no se entrara en detalle en los mismos en este documento.

El tamaño de la bodega puede ser de personal a muy grande, dependiendo del negocio y del volumen de los datos; se considera que si es menor a un giga byte es personal, entre uno y cincuenta giga bytes pequeño, entre cincuenta y cien giga bytes mediano, grande entre cien giga bytes y un tera byte, y muy grande mayor a un tera byte, teniendo en cuenta estos tamaños es recomendable desarrollar el diseño y estado de las componentes a utilizar en la bodega, al igual que el recurso físico, tiempo y costos de implementación.

Ambiente operacional de la Empresa

Ambiente de la Bodega

Spatial Data Warehouse

BD OLTP 010101010101010101 010101010101010101 010101010101010101 010101010101010101

Archivos Planos

ODS

Cartografia Existente

Plataforma de Producción

Data Marts

Datos de

Data

Análsis

Mining

Esquema global del Spatial Data Warehouse

OLAP

Fig. No. 18

24

Para sintetizar los datos que vamos a encontrar dentro de la bodega van a estar organizados y categorizados en: •

Dimensiones



Hechos



Datos de referencia



Datos Agregados



Metadatos.

Los hechos comprenden el volumen de la bodega, y pueden estar compuesto por millones de registros dependiendo la granularidad de los datos y los intervalos de tiempo de los mismos; recordemos que los hechos son accedidos por las dimensiones, un hecho es un dato instantáneo en el tiempo bajo condiciones definidas por las dimensiones por ejemplo una venta es un hecho, pero la venta corresponde a un producto, en una hora dada, en un día dado, en un lugar, costo y cliente especifico; este caso las dimensiones son tiempo, ubicación, producto y cliente, el costo es un dato agregado al hecho de la venta no una dimensión el cual depende del producto; es decir que el hecho es una instantánea de las bases de datos OLTP; los

registros de los hechos siempre son insertados, jamás

actualizados y el ciclo de refresque depende de la resolución temporal de los datos.

El registro del hecho posee una llave primaria compuesta que esta definida por las llaves primarias no naturales de las dimensiones; refiriéndose a llaves primarias no naturales a llaves plásticas o secuenciales inherentes al sistema y no al usuario, para facilitar la construcción de índices de manera compensada bajo algoritmos de hatching. En la bodega se pueden tener mas de una tabla de hechos, en caso de que a nivel de diseño se defina una sola tabla de hechos se conoce como modelo estrella, si existen mas tablas de dimensiones pero derivadas o segregadas a las dimensiones principales se conoce como modelo copo de nieve, o si existen mas tablas de hechos estas agregadas se conoce como modelo constelación, los datos de las tablas de hechos pueden ser aditivos si suman sobre todas las dimensiones, semi-aditivos si suman a lo largo de algunas dimensiones y no aditivos cuando no pueden sumarse a lo largo de ninguna dimensión. El diseño del modelo es una

25

tarea meticulosa y de cuidado si por algún caso obviamos una dimensión, y la deseamos agregar posteriormente y ya existe una implementación en la bodega es mejor abstenerse de hacerlo o rehacer todo el proyecto, ya que la tabla de hechos quedaría con vacíos e inconsistencias.

Dimension Tiempo

Dimension Ubicación

Tiempo_ID

Lugar_ID

Tabla de Hechos

Fecha_ID Año_ID

Sector _ID Estrato _ID

Mes _ID

Tabla de Hechos Ventas

Geometria_ID

Día _ID

Tiempo_ID

Ubicación _ID

Dimensiones

Dimensiones

Lugar_ID Cliente_ID Producto_ID Unidades Ventas Dimension Cliente Cliente _ID Cuenta _ID

Precio

Dimension Producto

Costo

Producto _ID

Margen

Item _ID

Envio _ID

Familia _ID

Segmento _ID

Clase _ID

Fig. No. 19

Modelo estrella

Las dimensiones de los datos califican y manejan las consultas y restricciones del usuario, generalmente las dimensiones son las áreas temáticas de interés del negocio, o determinadas a partir de las mismas, por ejemplo en área de clientes, puntos de venta, centro de producción, etc. Las cuales actúan para un único fin, por ejemplo una venta, por tal motivo la definición de dimensiones implica un diseño imperativo, debido a que la intersección de las mismas es la que permite localizar los datos en la tabla de hechos, las relaciones se desarrollan a partir de las llaves primarias, recordemos que la llave primaria de la tabla de hechos está formada por la concatenación de las llaves primarias de las dimensiones,

las tablas de las dimensiones se componen de datos textuales, son de

pequeñas magnitudes, sus valores son discretos y desnormalizados, los cambios deben ser

26

capturados no refrescados. Recordemos que en la normalización se pretende eliminar la redundancia, la repetición de datos y las llaves deben ir en independientes columnas, en este tipo de modelos se requiere precisamente no evitar esto para agilizar los procesos de consultas y evitar incurrir en complejas y largas uniones para acceder al dato consultado, de igual manera desarrollar e incluir dentro de la base de datos los totales mas solicitados o los valores agregados para las generalizaciones. En un Spatial Data Warehouse la dimensión tiempo es obligatoria, la definición de la granularidad y jerarquía de la misma depende de la dinámica del negocio, toda la información dentro de la bodega posee su sello de tiempo que determina la ocurrencia y ubicación con respecto a otros elementos de iguales condiciones; no es igual el 25 de diciembre al 25 de mayo. Los datos de referencia dentro de la bodega permiten apoyar la administración de datos dimensiónales, reduciendo significativamente los volúmenes de la bodega, proveen referencia para los datos codificados; simplemente es mayor información sobre detalles específicos o descripciones de campos de las dimensiones. Los datos agregados son todas aquellas sumarizaciones o acumulaciones preestablecidas y almacenadas dentro de la bodega para agilizar consultas, no solamente pueden ser sumas, también se pueden implementar promedios, máximos, totales por sectores, porcentajes, etc. Dependiendo las necesidades del negocio, las mismas se pueden desarrollar en la etapa de diseño o posteriormente a la implementación de acuerdo al desempeño de la bodega, las sumarizaciones son basadas en los hechos, calculadas por datos de las dimensiones, y residen generalmente en la misma tabla de los hechos y en algunos casos en tablas diferentes siendo estas nuevas tablas de hechos derivadas. Es muy importante en el ambient e de la bodega documentar todos los procesos, tipos de datos y estructuras de datos a través de Metadatos, es decir información de los datos, los mismos son los que permiten navegar a lo largo de todos los procesos y datos para cualquier usuario, los Metadatos brindan información de localización, estructura, y significado de los datos, básicamente mapean los datos; en el Spatial Data Warehouse encontramos diferentes tipos de Metadatos:

27



Los Metadatos de los procesos ETT, referentes al modelo lógico y físico, de las fuentes de datos de las bases de datos operacionales, estos contienen las reglas de extracción, depuración y traslado de los datos a la bodega.



Metadatos para usuarios finales que les permitan navegar por los datos y sirvan de documentación para las herramientas de análisis que se empleen.



Metadatos operacionales, los cuales contienen los relatos de las diferentes tareas de cargue, y procesos de acceso, este metadato es usado para fijar y desempeñar análisis sobre las condiciones de la bodega.



Metadatos geográficos, son los encargados de documentar todos los geo objetos, para poder desarrollar las diferentes operaciones y manipulaciones de los mismos, no solo a nivel operacional si no de usuario final, es un híbrido de los tres tipos de Metadatos anteriores, pero en un contexto geográfico.

2.3.

MODELAMIENTO DE DATOS

Los procesos y etapas que se desarrollan en el modelamiento de los datos de un Spatial Data Warehouse son similares a los que se desarrollan en el diseño de un sistema de base de datos normal o en un sistema de información geográfica; es lógico entender que el modelamiento del Spatial Data Warehouse se basa en las consideraciones de los dos sistemas en mención. Encontrando un modelamiento conceptual, un modelo lógico y uno físico, independiente a la herramienta en la que se desee implementar los dos primeros modelos. Modelo Conceptual Modelo Logico Modelo Físico Sistemas

Modelo Logico Modelo Físico Bodega

Operacionales Modelamiento de Datos

Fig. No. 20

28

Los modelos son una representación lógica de cómo los datos aparecen físicamente en los diferentes niveles de la base de datos. Estos son análogos a los planes que se deben seguir para las nuevas construcciones que definen el tamaño, elementos, y apariencia de la construcción, ya sea de una base de datos o un SIG, Categóricamente los modelos mas consecuentes y estándares que encontramos en el modelamiento de datos son: •

Modelo conceptual, es un alto nivel de definición de los datos y procesos utilizados para confirmar los alcances del proyecto, en este se identifican las entidades, relaciones y funciones del negocio direccionadas para el proyecto.



Modelo lógico, es la definición de los datos y procesos del negocio, incluidos en el sistema, este modelo es independiente de las limitantes y consideraciones físicas; como propiedad orgánica, ubicación geográfica, o tecnología de implementación.



Modelo físico, es una descripción de las estructuras internas de los datos y procesos usados en el sistema. Este modelo define la implementación física del modelo lógico.



Diagrama o modelo entidad relación, esquematiza gráficamente los ítem de interés en una organización (entidades), y las relaciones existentes entre las entidades.



Modelo Empresarial, es un modelo global de la organización completa del negocio, este incluye una descomposición jerárquica de las funciones del negocio, y el modelo entidad relación de los datos requeridos para el soporte de la organización, este modelo se suele denominar por algunos autores como modelo corporativo.

El modelo de datos empresarial es uno de muchos que soporta toda la estrategia de la tecnología de la información, este es el modelo lógico de los datos operacionales que el negocio tiene actualmente sistematizados. El modelo empresarial es: •

El modelo lógico del sistema operacional actual y el soporte de las estructuras de datos actuales.



Diseñado para los procesos transaccionales actuales.

29



La fuente de las reglas del negocio, contiene los datos normalizados.

Cuando se inicia el proceso de modelamiento de los datos para el Spatial Data Warehouse, un buen punto de partida es el modelo empresarial; como ya habíamos mencionado el proyecto de la bodega puede iniciarse con el negocio, caso en el cual la premisa anterior no estaría fundamentada, pero recordemos que en la mayoría de situaciones el negocio ya esta consolidado con una producción y un sistema transaccional operando, bajo estas circunstancias la consideración en mención tiene validez, de tal manera que el modelo empresarial es un buen esquema para mapear los diferentes datos que se manejan actualmente, por ende se puede determinar enfocadamente las necesidades del negocio, las reglas que rigen los procesos y lo mas importante medir los alcances, granularidad, temporalidad y tiempos de refresque de la bodega, a si como determinar las falencias y redundancias de información, nos permite unificar los distintos modelos de datos en las diferentes áreas del negocio, consolidando lo que en muchos organizaciones se maneja en el departamento de SIG, lo que se maneja en el departamento de sistemas divididos, entre otros, todo enmarcado en la situación actual de la empresa. El desarrollo del modelamiento es interactivo y retroalimenticio, un buen modelamiento no nos garantiza el éxito de la bodega, pero de lo contrario si garantizamos el fracaso de la misma, Oracle corporation, postula unos pasos para desarrollar el modelamiento de datos para un Data Warehouse, siendo este uno de los procedimientos mas aceptados en el mundo; y considerando que los datos geográficos son un tipo abstracto de dato mas en el modelamiento, estos procedimientos aplican con ciertas consideraciones especiales al Spatial Data Warehouse, por cada área objeto del estudio, usted normalmente puede llevar a cabo estos pasos a través de un desarrollo interactivo:

1. Determinar una estrategia global para la implementación de la bodega, incremental y por niveles de la empresa. 2. Determinar los requerimientos de la arquitectura técnica. 3. Considerar la calidad de los datos, y los requerimientos para depurar y limpiar los datos que van a ser la base de la bodega.

30

4. Estime los costos del proyecto, determine los especialistas y los recursos requeridos. 5. Evalué y seleccione las herramientas a utilizar, provea de herramientas tipo SIG, y tecnologías de controles que permitan SIG embebido. 6.

Diseñe el plan y costo del proyecto, obtenga consolidados y recursos.

7. Identifique y analice las áreas objeto del escenario del negocio propuesto. 8. Recopile los requerimientos de datos e información para los usuarios, reglas del negocio, y reportes. 9. Desarrolle el modelo lógico. 10. Mapee las entidades, atributos y relaciones desde el modelo operaciona l normalizado si este existe, por otra parte mapee el modelo de la bodega desde las fuentes de datos. 11. Desarrolle un proceso de re- ingeniería especifica al sistema de las fuentes de los datos, este paso permite que los procesos contenciosos en la implementación de la bodega sean manipulables, para evitar cargues adicionales de los recursos del negocio. 12. Diseñe la base de datos alrededor de la tecnología, relacional, objeto relacional o multidimensional, teniendo en cuenta que para bodegas espaciales lo recomendable es un híbrido entre la objeto relacional y la multidimensional. 13. Realice pruebas de los conceptos de tal manera que se puedan verificar y reparar, involucrando a los usuarios y equipos técnicos como: -

Encargados del modelo de la arquitectura del repositorio de la bodega de datos espaciales.

-

Encargados de crear todos los procedimientos y rutinas ETT.

-

Encargados de crear y actualizar Metadatos.

-

Especialistas en sistemas de información geográfica.

14. Maneje las expectativas de los usuarios y alcances que se han adquirido como compromiso.

31

Una vez a desarrollado todos estos procesos, se debe determinar e identificar todas las tareas, colocando especial atención en las repetitivas, para su respectiva automatización; definiendo y asignando consistentemente los miembros del grupo que van a desarrollar las tareas de acuerdo a su desempeño; a si mismo determinar medios para medir la calidad e integridad de las tareas, y definir la dirección y coordinación de las mismas. Algunas de las tareas mas importantes y generales que se van a encontrar en cualquier proyecto recordemos que son: -

Adquisición y transformación de los datos desde los sistemas fuentes.

-

Habilitación espacial de la información.

-

Definición y acceso de los Metadatos.

-

Creación del diseño técnico de la bodega.

-

Proveer un acceso fácil y eficiente de los datos.

-

Definir una estrategia de la calidad de los datos.

-

Habilitando las herramientas de usuario final o front end.

2.3.1. Spatial data Warehouse modelo estrella

Dimension Tiempo

Dimension Tienda

Tiempo_ID Fecha_ID

Tienda_ID

Tabla de Hechos

Año_ID

Sector _ID Estrato _ID

Mes _ID

Tabla de Hechos Ventas

Geometria

Día _ID

Tiempo_ID

Ubicación_espacial

Dimensiones

Dimensiones

Lugar_ID Cliente_ID Producto_ID Unidades Ventas Dimension Cliente

Precio

Cliente _ID

Costo

Cuenta _ID

Margen

Dimension Producto Producto _ID Item _ID

Envio _ID

Familia _ID

Segmento _ID

Prod_descripción

Modelo Estrella

Fig. No. 21

32

Como ya hemos visto la tabla central es la tabla de hechos, y radiando encontramos las tablas de dimensiones, y notamos que el modelo esta desnormalizado, y encontramos operaciones dentro de los hechos como el margen, entrando este como dato agregado. Las ventajas de este modelo es que es fácil de entender y responder a las consultas de los usuarios, optimizando y reduciendo el numero físico de uniones requeridas entre los hechos y las dimensiones, basta con definir valores para las dimensiones y encontrar el hecho correspondiente, de igual manera los Metadatos en este modelo son fáciles de documentar y mantener, soportado por casi todas las herramientas de usuario final, sin embargo es el menos robusto para el cargue y es el mas lento de construir por el nivel de desnormalización, y este no es fácil de usar si usted necesita el mantenimiento histórico de los datos.

2.3.2. Spatial data Warehouse copo de nieve

Dimension Producto

Dimension Tienda

Tabla Seccion

Producto _ID

Tienda_ID

Seccion_ID

Prod_descripción

Tienda_desc

Seccion_desc

Sección_id

Geometria

Geometria

Ubicación_espacial

Tabla de Hechos Tabla de Hechos Ventas

Ubicación_espacial

Tiempo_ID

Dimesiones

Tienda_ID

Dimensiones

Cliente_ID Producto_ID Unidades Ventas Precio Costo Margen

Dimension Tiempo Tiempo_ID

Dimension Cliente

Tabla Cuenta

Tabla Segmento

Semana_ID

Cliente _ID

Cuenta _ID

Segmento _ID

Periodo_ID

Cliente_desc

Cuenta_desc

Segmento_nombre

Año _ID

Cuenta _ID

Segmento _ID

Segmento_desc

Fig. No. 22 Modelo copo de nieve

33

El modelo copo de nieve es mas cercano a un modelo entidad relación, que al clásico modelo estrella, porque las dimensiones de los datos están normalizadas. Desarrollando un modelo copo de nieve se puede desarrollar clases de jerarquías fuera de las dimensiones (datos normalizados), que permitan análisis de lo general a lo particular y viceversa. El modelo copo de nieve es muy conocido en el contexto de herramientas de Sistemas de soporte de decisiones DSS (Decision support system), como en productos Oracle Express donde se puede usar directamente; este modelo es muy flexible y puede ser implementado después de que se haya desarrollado un modelo estrella. El modelo copo de nieve puede tener estos inconvenientes: -

Un modelo copo de nieve con múltiples dimensiones cada una de ellas con múltiples jerarquías crea un gran numero de dimensione s , lo cual hace un modelo inmanejable, sin embargo él nunca es tan grande como, o tan inmanejable como, un modelo estrella.

-

Muchas uniones en las consultas, pueden sacrificar el desempeño del sistema.

La principal razón para usar modelos copo de nieve es la posibilidad de segregar los datos de las dimensiones y proveer un modelo que sustente los requerimientos de diseño que usted necesita. 2.3.3. Spatial data Warehouse constelación Dimension Cliente

Dimension Tiempo

Dimensiones Tablas de Hechos Tabla de Hechos Ventas

Tabla Hechos Ventas Sumarizadas

Unidades

Sum_Promedio_unidades

Ventas

Sum_Promedio_ventas

Precio

Sum_Promedio_precio

Costo

Sum_Promedio_costo

Dimension Producto

Dimension Tienda

Dimensiones Modelo Constelación

Fig. No. 23

34

El modelo constelación esta compuesto por una serie de modelos estrellas, donde existe una tabla de hechos principal, y una serie de tablas de hechos agregadas o auxiliares, las cuales pueden ser sumarizaciones de la principal, no necesariamente están relacionadas con las mismas dimensiones de la principal, puede relacionarse con un subconjunto de ellas o con nuevas dimensiones de acuerdo a los requerimientos del sistema.

En el modelo de la bodega (modelo multidimensional), puede ser tan extenso como se requiera, de tal manera que se pueda ver similar a un modelo entidad relación, sobre todo si estamos hablando de un modelo copo de nieve, pero independiente al que se utilice existe una terminología común asociada a este: •

Una dimensión define como están los datos organizados lógicamente, esta contiene uno o mas atributos, y en muchos de ellos puede existir una jerarquía si este esta normalizado, las dimensiones proveen de recursos para analizar el negocio.



Un atributo es una característica de una dimensión, tal como color, altura, o tamaño, los atributos pueden ser numéricos, alfanuméricos, imágenes, sonidos, videos, u objetos geográficos, entre otros muchos mas tipos de datos.



Una dimensión posee mas de un atributo.



En la dimensión tiempo los atributos son por ejemplo día, semana, mes, año, si es día de quincena, etc.



La jerarquía es una relación lógica entre dos atributos dentro de una dimensión, al desarrollar el diagrama hay que procurar dejar lo general en la parte superior de la hoja y vaya diseminado lo particular hacia abajo.



Una relación es como el atributo relacionado interactúa con otro dentro de una jerarquía, las relaciones pueden ser explicitas o implícitas, las relaciones explicitas son las que se pueden modelar a partir de atributos directos y comunes dentro del sistema y están en línea de directa de una jerarquía, por ejemplo un país tiene muchas ciudades, donde el código de la ciudad hereda el código del país, son las mas comunes en sistemas de bases de datos convencionales; Mientras las relaciones implícitas ocurren en la vida real pero su relación no es de vista directa, por ejemplo un país tiene muchos ríos pero esos ríos pueden pasar por muchos países,

35

existe una relación implícita, el código del rió nada tiene que ver con el código del país, pero la relación existe, y la misma se resuelve relacionado espacialmente los dos entes, son las más comunes en los sistemas de información geográfica. Las relaciones como podemos notar poseen una cardinalidad la cual define la magnitud o grado de la relación, la cardinalidad puede ser uno a uno, uno a muchos, o muchos a muchos; en muchos textos se permuta él termino cardinalidad con él termino multiplicidad, pero el primero es en un contexto relacional y el segundo en un contexto objeto relacional donde encontramos mas categorías de cardinalidad. •

Los hechos son las columnas de los datos relacionados a las tablas de dimensiones por las llaves.

La ventaja de manejar jerarquías radica en poder analizar de lo general a lo particular lo que se conoce como drill – down drill - up, como su traducción lo indica ir taladrando en el detalle de los datos, o ir alo general de los datos.

Drill - up

Drill - down

Fig. No. 24

Jerarquía de las consultas

Es bueno tener en cuenta que en los sistemas tradicionales OLTP, la dimensión tiempo no es modelada a diferencia de los Spatial Data Warehouse, donde el sello de tiempo del dato es imprescindible, y por ende su diseño es de cuidado, entre lo que debemos tener en cuenta cabe anotar que el tiempo no es una simple secuencia cronología representada numéricamente, si no que posee fechas especiales que inciden notablemente en el negocio si es viernes o no, o si ese viernes es de quincena o no, características que cualifican las

36

diferentes fechas; y que se pueden necesitar una historia secuencial especial para ciertos datos. De igual manera es común que los clientes necesiten totales por alguna unidad de tiempo, donde algunas sumas pueden requerir demasiado tiempo, de tal manera que se deban prever para desarrollar y almacenar las respectivas operaciones, y una ultima consideración a tener en cuenta es que el tiempo nos permite construir las diferentes versiones de la información así como de los datos. Diseñar esta dimensión no es tarea fácil, es importante detenerse a analizar la temporalidad de los datos, la historia, flexibilidad y precisión de los mismos, para determinar el modelo mas eficiente que envuelva satisfactoriamente los datos.

Tabla de Hechos

Tabla de Hechos

Tabla de Hechos

Dia_ID

Dia_ID

Dia_ID

Dimension Tiempo

Dimension Tiempo

Dia_ID

Dia_ID

Dia_ID

Mes_ID

Mes_ID

Trimestre_ID

Trimestre_ID

Semestre_ID

Semestre_ID

Año_ID

Año_ID Mes_Fiscal_ID

Mes_ID

Trimestre_ID

Semestre_ID

Trimestre_ fiscal_ID Semestre_fiscal_ID

Año_ID

Año_ fiscal _ID

Fig. No. 25

Modelando la dimensión tiempo

Otras consideraciones que se deben tener en cuenta para el afinamiento de la bodega son las sumarizaciones que van ha aparecer como datos agregados en el modelo, las mismas se pueden definir en la etapa de diseño o posteriormente, aunque generalmente se desarrollan cuando la bodega esta en marcha y los usuarios con el uso de la misma establecen cuales son las necesarias, las sumarizaciones no solamente son de datos numéricos, recordemos

37

que para ciertos análisis geográficos especiales también se desarrollan; si todo este tipo de operaciones devuelven una gran cantidad de datos y consumen mucho recurso de maquina es recomendable estructurarlas y almacenarlas en nuevas tablas auxiliares, el refresque de las mismas se puede desarrollar simultaneo con el ciclo de alimentación de la bodega, o en intervalos de tiempo diferentes de acuerdo a la operación en ejecución; definir una buena estrategia de implementación de datos sumariados, ayúdese en los usuarios, en el administrador de la bodega, y en las estadísticas del motor de la base de datos de las operaciones que congestionan el sistema y su frecuencia. Recuerde que depend iendo el modelo de la bodega el mantenimiento de la historia de los datos puede ser mas fácil o compleja, la historia del dato es diferente al sello temporal del dato, circunstancia obligatoria en la bodega, la historia se refiere a las versiones de los datos por ejemplo el cliente Pepito Pérez hasta el mes pasado era soltero de ahí en adelante es casado, entonces en la tabla de clientes existe un único registro para Pepito pero en la tabla de historia de los clientes existen dos para el mismo con las condiciones cambiantes, en el caso de los datos espaciales las versiones son un caso mas frecuente y mas importante porque sobre las mismas se desarrollan muchos análisis, el análisis de requerimientos nos determinara si necesitamos o no este tipo de situaciones. Tabla de Hechos Tabla de Hechos Ventas Tiempo_ID Tienda_ID Cliente_ID Producto_ID Unidades Ventas Precio Costo

Dimesion

Margen

Dimension Cliente

Tabla Historia Cliente

Cliente _ID

Cuenta _ID

Nombre

1

1

Pepito Pérez Soltero

1

30-06-1996

2

1

Pepito Pérez Casado

2

30-06-2000

3

2

Xxxxx Yxxxx Soltero

1

30-06-1996

3

Zzzzzz Www Soltero

1

30-06-1996

Estado_civil Version

Fecha

Fig. No. 26 Modelando la historia del dato

38

No olvidar que todos los procesos deben ser documentados, existen herramientas que permiten ir documentando los procesos paralelo a su diseño, es ejemplo de las herramientas de Oracle, no lo deje para el final o sus Metadatos no serán los mas recomendables, evitar mezclar los modelos de la bodega (estrella, copo de nieve y constelación) porque conseguirá un esquema Mismas, el cual no es un modelo si no la situación de tener un modelo poco entendible combinando todos los modelos existentes, su mantenimiento, cargue y afinamiento serán complicados; lo mas importante siempre es acompañarse de los usuarios, revisar, comunicar, publicar y distribuir todos los avances del proyecto, para eventuales correcciones, la bodega va a ser el sustento y soporte para la toma de todas las decisiones del negocio, si no posee los criterios y necesidades de los que deciden no cumple con la finalidad de la bodega.

2.3.4. Del modelo corporativo al modelo Spatial Data Warehouse Partir del modelo corporativo para establecer el modelo de la bodega es un buen camino, aunque no es obligatorio iniciar por este, la ventaja de mismo radica en que se garantiza abarcar todo el modelo lógico de los sistemas operacionales y reglas vigentes en la empresa, y el diseño de los procesos ETT en fácilmente manipulable; en algunos casos como antes habíamos mencionado no existe un modelo corporativo por diferentes motivos, algunos expertos en el tema prefieren desarrollar uno y transformarlo al de la bodega, otros mas versados simplemente en estas situaciones inician directamente con el de la bodega, lo importante es que sea operable, funcional y sea lo que se necesite. La transformación de un modelo al otro es un proceso secuencial sencillo de entender, el cual describiremos paso a paso a continuación: 1. Remueva todos los datos operacionales, derivados y desnormalice el modelo corporativo. En el ejemplo se remueven los atributos precedidos de (-), y se agregan los precedidos de (+), todos en color azul.

39

Modelo corporativo VENTAS #* Ventas_ID

CLIENTE

ITEM_VENTAS

* Numero_Orden

#* Cliente_ID

#* Item_Venta_ID

* Fecha

* Nombre

* Precio

º Comentarios

* Dirección

* Costo

º Asignación

* Telefono

º Comentarios

* Creado_por

º Descripcion

* Credito_ver_por TIENDA

* Empleado_ver_ID

#* Tienda_ID * Geometria_ID * Ubicación º Descripción º Fecha_creación

SECTOR

CUENTA_CLIENTE

PRODUCTO

#* Cuenta_ID

#* Producto_ID

º Descripción

* Item_ID

* Creada_por

* Familia_ID

* Fecha_contrato

* Clase_ID * Creado_por

#* Sector_ID

* Descripción

* Sector_Desc * Estrato_ID * Estrato_Desc

Fig. No. 27 Modelo Corporativo de ejemplo

Remover Datos operacionales VENTAS #* Ventas_ID

CLIENTE

ITEM_VENTAS

* Numero_Orden

#* Cliente_ID

#* Item_Venta_ID

* Fecha

* Nombre

* Precio

- Comentarios

* Dirección

* Costo

- Asignación

* Telefono

- Comentarios

- Creado_por

- Descripcion

- Credito_ver_por TIENDA

- Empleado_ver_ID

#* Tienda_ID * Geometria_ID * Ubicación - Descripción - Fecha_creación

SECTOR #* Sector_ID - Sector_Desc

CUENTA_CLIENTE

PRODUCTO

#* Cuenta_ID

#* Producto_ID

- Descripción

* Item_ID

- Creada_por

* Familia_ID

- Fecha_contrato

* Clase_ID - Creado_por - Descripción

* Estrato_ID - Estrato_Desc

Fig. No. 28 Primer paso remover datos operacionales

40

Modelo corporativo sin datos operacionales

VENTAS #* Ventas_ID * Numero_Orden * Fecha

CLIENTE

ITEM_VENTAS

#* Cliente_ID

#* Item_Venta_ID

* Nombre

* Precio

* Dirección

* Costo

* Telefono

TIENDA #* Tienda_ID * Geometria_ID

CUENTA_CLIENTE

* Ubicación

#* Cuenta_ID

PRODUCTO #* Producto_ID * Item_ID * Familia_ID

SECTOR

* Clase_ID

#* Sector_ID * Estrato_ID

Fig. No. 29 Primer paso modelo corporativo sin datos operacionales

2. Adicionar el elemento tiempo al modelo si este no existe, el tiempo es una estructura variante por lo que es necesario posteriormente extraerlo a una tabla externa de las iniciales, si el tiempo es un punto de referencia de un inicio o un final simplemente se puede almacenar permanentemente en la misma tabla como dos atributos adicionales.

Adicionar el tiempo VENTAS #* Ventas_ID

CLIENTE

ITEM_VENTAS

* Numero_Orden

#* Cliente_ID

#* Item_Venta_ID

* Fecha

* Nombre

* Precio

* Dirección

* Costo + Fecha_instantanea

* Telefono + Fecha_instantanea TIENDA #* Tienda_ID * Geometria_ID * Ubicación + Fecha_instantanea

CUENTA_CLIENTE #* Cuenta_ID + Fecha_instantanea

PRODUCTO #* Producto_ID * Item_ID

SECTOR

* Familia_ID

#* Sector_ID

* Clase_ID + Fecha_instantanea

* Estrato_ID + Fecha_instantanea

Fig. No. 30 Segundo paso adicionar el elemento tiempo

41

3. Adicionar datos derivados al modelo, en este paso usted desnormaliza la estructura, y adiciona datos derivados para reducir la cantidad de procesos requeridos; En el modelo relacional los datos derivados no son almacenados son calculados en tiempo de ejecución; habilite espacialmente la información que lo requiera.

Adicionar datos derivados VENTAS #* Ventas_ID * Numero_Orden

CLIENTE

ITEM_VENTAS

* Fecha

#* Cliente_ID

#* Item_Venta_ID

+ Total_ventas + Precio + Costo + Margen

* Nombre

* Precio

* Dirección

* Costo

* Telefono

* Fecha_instantanea

* Fecha_instantanea + Total_compras TIENDA #* Tienda_ID * Geometria_ID * Ubicación * Fecha_instantanea + Total_tiendas

CUENTA_CLIENTE

PRODUCTO

#* Cuenta_ID * Fecha_instantanea

#* Producto_ID * Item_ID * Familia_ID

SECTOR

* Clase_ID

#* Sector_ID

* Fecha_instantanea

* Estrato_ID

+ Total_Productos

* Fecha_instantanea

Fig. No. 31 Tercer paso adicionar datos derivados

4. Crear relaciones que determinen las reglas del negocio entre los datos, hasta esta fase las entidades no contienen las llaves primarias y foráneas que definen las relaciones.

42

VENTAS

Crear relaciones

#* Ventas_ID + Cliente_ID * Numero_Orden

CLIENTE

ITEM_VENTAS

* Fecha

#* Cliente_ID

#* Item_Venta_ID

* Total_ventas * Precio * Costo * Margen

* Nombre

+ Ventas_ID

* Dirección

* Precio

* Telefono

* Costo

* Fecha_instantanea

* Fecha_instantanea

* Total_compras TIENDA

+ Cuenta_ID

#* Tienda_ID * Geometria_ID * Ubicación * Fecha_instantanea

CUENTA_CLIENTE

PRODUCTO

#* Cuenta_ID * Fecha_instantanea

#* Producto_ID

* Total_tiendas * Item_ID * Familia_ID SECTOR

* Clase_ID

#* Sector_ID

* Fecha_instantanea

* Estrato_ID

* Total_Productos

* Fecha_instantanea

Fig. No. 32 Cuarto paso crear relaciones

5. Juntar datos afines, determine cuales de estas tablas contienen datos afines que puedan ser unidos o combinados por las llaves comunes, recuerde que la idea es desnormalizar, en este paso tómese su tiempo y ayúdese de herramientas para garantizar la calidad de los datos, ya que usted puede unir datos de distintas fuentes y estructuras.

VENTAS

Juntar datos Afines

#* Ventas_ID * Cliente_ID * Numero_Orden

CLIENTE

ITEM_VENTAS

ITEM_INVENTARIO

* Fecha

#* Cliente_ID

#* Item_Venta_ID

+ Producto_ID

* Total_ventas * Precio * Costo * Margen

* Nombre

* Ventas_ID

+ Bodega_ID

* Dirección

* Precio

+ Tiempo_orden

* Telefono

* Costo

+ Agotado

* Fecha_instantanea

* Fecha_instantanea

+ Vendido

* Total_compras

+ Bodega_ID

* Cuenta_ID

+ Tiempo_orden

TIENDA #* Tienda_ID

+ Agotado

* Geometria_ID

+ Vendido

* Ubicación * Fecha_instantanea * Total_tiendas

CUENTA_CLIENTE #* Cuenta_ID * Fecha_instantanea

PRODUCTO #* Producto_ID

SECTOR #* Sector_ID * Estrato_ID * Fecha_instantanea

* Item_ID * Familia_ID * Clase_ID * Fecha_instantanea * Total_Productos

Quinto paso juntar datos afines

Fig. No. 33

43

6. Segregar o agregar datos si es apropiado, cree arreglos de datos que permitan dar a conocer o especificar las entidades en tablas diferentes, organice los datos por frecuencia de actualización en tipos de datos separados, esto involucra crear nuevas tablas de detalles o información histórica, evalué si la información geográfica es un nicho de su negocio, si es así segréguela en una nueva dimensión. VENTAS

Segregar datos (1)

#* Ventas_ID * Cliente_ID * Numero_Orden

CLIENTE

DETALLE_CLIENTE

ITEM_VENTAS

* Fecha

#* Cliente_ID

+ Cliente_ID

#* Item_Venta_ID

* Total_ventas * Precio * Costo * Margen

* Nombre

+ Dirección

* Ventas_ID

* Fecha_instantanea

+ Telefono

* Precio

+ Total_compras

* Costo * Fecha_instantanea * Bodega_ID

TIENDA

* Tiempo_orden

#* Tienda_ID

* Agotado

* Geometria_ID

* Vendido

* Ubicación * Fecha_instantanea * Total_tiendas

SECTOR

PRODUCTO

HISTORIA_PROD

#* Producto_ID

+ Producto_ID

* Item_ID

+ Fecha_instantanea

* Familia_ID

+ Item_ID

* Clase_ID

+ Familia_ID

* Fecha_instantanea

+ Clase_ID

* Total_Productos

+ Versión

#* Sector_ID * Estrato_ID * Fecha_instantanea

Fig. No. 34

Sexto paso segregar datos(1)

VENTAS

Segregar datos (2)

#* Ventas_ID * Cliente_ID * Numero_Orden * Fecha * Total_ventas * Precio * Costo * Margen + Bodega_ID

CLIENTE

DETALLE_CLIENTE

ITEM_VENTAS

#* Cliente_ID

#* Cliente_ID

#* Item_Venta_ID

* Nombre

* Dirección

* Ventas_ID

* Fecha_instantanea

* Telefono

* Precio

* Total_compras

* Costo

+ Tiempo_odern

* Fecha_instantanea

+ Agotado

* Bodega_ID

+ Vendido

* Tiempo_orden * Agotado TIENDA

* Vendido

#* Tienda_ID * Geometria_ID * Ubicación * Fecha_instantanea

PRODUCTO

HISTORIA_PROD

* Total_tiendas

#* Producto_ID

#* Producto_ID

* Item_ID

* Fecha_instantanea

SECTOR

* Familia_ID

* Item_ID

#* Sector_ID

* Clase_ID

* Familia_ID

* Estrato_ID

* Fecha_instantanea

* Clase_ID

* Fecha_instantanea

* Total_Productos

* Versión

Sexto paso segregar datos(2)

Fig. No. 35

44

7. Consolidar la dimensión tiempo, como ya habíamos mencionado en el paso dos el elemento tiempo no siempre es un valor de referencia, si no es una estructura dinámica, y como hemos tratado en todo el texto una componente obligatoria de la bodega; para implementar la dimens ión tiempo vasta con analizar de los elementos de tiempo que adicionados en el paso dos cuales son dinámicos y ocurren simultáneamente para consolidarlos en una única dimensión.

Consolidar la dimension tiempo TIEMPO + Tiempo_ID + Dia_ID + Mes_ID + Trimestre_ID

VENTAS

+ Semestre_ID

#* Ventas_ID

+ Año_ID

* Cliente_ID

CLIENTE

DETALLE_CLIENTE

#* Cliente_ID

#* Cliente_ID

* Nombre

* Dirección

- Fecha_instantanea

* Telefono * Total_compras

* Numero_Orden * Fecha

#* Tienda_ID

* Total_ventas * Precio * Costo * Margen

* Geometria_ID

* Bodega_ID

* Ubicación

- Tiempo_orden

- Fecha_instantanea

* Agotado

PRODUCTO

HISTORIA_PROD

* Total_tiendas

* Vendido

#* Producto_ID

#* Producto_ID

* Item_ID

* Fecha_instantanea

* Familia_ID

* Item_ID

* Clase_ID

* Familia_ID

- Fecha_instantanea

* Clase_ID

* Total_Productos

* Versión

TIENDA

SECTOR #* Sector_ID * Estrato_ID - Fecha_instantanea

Fig. No. 36 Séptimo paso consolidar la dimensión tiempo

8. Aplicar datos contextuales, este paso esta compuesto por dos fases: -

Aplique criterio contextual simple a los datos, como la estructura de cada atributo o datos que permitan codificar y medir los diferentes atributos.

-

Aplique criterio contextual complejo a los datos, como información descriptiva del negocio o información externa de la empresa producida por otros entes, así como la información geográfica base de referencia.

45

Aplicar datos contextuales TIEMPO #* Tiempo_ID * Dia_ID

CLIENTE

DETALLE_CLIENTE

#* Cliente_ID

#* Cliente_ID

* Nombre

* Dirección * Telefono

* Mes_ID * Trimestre_ID

VENTAS

* Semestre_ID

#* Ventas_ID

* Año_ID

* Cliente_ID

+ Quincena

* Numero_Orden

+ Temporada

* Fecha

#* Tienda_ID

* Total_ventas * Precio * Costo * Margen

* Geometria_ID

* Bodega_ID

* Ubicación

* Agotado

* Total_tiendas

* Vendido

TIENDA

* Total_compras + Edad + Sexo + Estado_civil

PRODUCTO

HISTORIA_PROD

#* Producto_ID

#* Producto_ID

* Item_ID

* Fecha_instantanea

SECTOR

* Familia_ID

* Item_ID

#* Sector_ID

* Clase_ID

* Familia_ID

* Estrato_ID

* Total_Productos

* Clase_ID

+ Vigencia

* Versión

Fig. No. 37

Octavo paso aplicar datos contextuales

9. finalmente sintetice todo el modelo, revíselo realícele los ajustes perfectos, documéntelo así como los Metadatos, y publíquelo como la primera aproximación del modelo de la bodega, explíquelo y discútalo con el personal técnico y del área de sistemas desarrollándole las correcciones pertinentes, luego desarrolle el mismo procedimiento con los usuarios de los distintos niveles; una vez se disponga de un modelo mas afinado

46

Sintetizando todo TIEMPO

CLIENTE

DETALLE_CLIENTE

Tiempo_ID

Cliente_ID

Cliente_ID

Nombre

Dirección

Dia_ID

Telefono

Mes_ID Trimestre_ID

VENTAS

Semestre_ID

Ventas_ID

Año_ID

Cliente_ID

Quincena

Tiempo_ID

Temporada

Producto_ID

Total_compras Edad Sexo Estado_civil

Tienda_ID TIENDA

Numero_Orden

#* Tienda_ID

Fecha

* Geometria_ID

Total_ventas Precio Costo Margen

PRODUCTO

HISTORIA_PROD

Bodega_ID

Producto_ID

Producto_ID

Agotado

Item_ID

Fecha_instantanea

Vendido

Familia_ID

Item_ID

Sector_ID

Clase_ID

Familia_ID

Estrato_ID

Total_Productos

Clase_ID

* Ubicación * Total_tiendas

SECTOR

Vigencia

Versión

Noveno paso sintetice todo el modelo de la bodega.

Fig. No. 38

47

3. APROXIMACIÓN METODOLOGÍCA DE UN SPATIAL DATA WAREHOUSE

Esbozar una metodología de

Spatial Data Warehouse, consiste en sintetizar las

metodologías de sistemas de información tradicionales con las de sistemas de información geográfica, y como todos sabemos que los SIG son una particularidad de los SI, la aproximación consistirá en desarrollar una metodología que abarque toda la dirección del proyecto teniendo particular enfoque con todo lo que implica el proyecto Spatial Data Warehouse. Al inicio de cualquier proyecto, la administración debe proveer y asignar una serie de tareas para la plantación y organización del mismo, durante la ejecución la administración debe suministrar todas aquellas tareas para las diferentes fases del proyecto , de tal manera que se pueda controlar y terminar cada una de ellas. Y al final del proyecto la administración debe disponer de guías para la finalización, cubrimiento, y divulgación de lo que representa el proyecto.

Recordemos que los principales componentes de cualquier metodología de Spatial Data Warehouse están enmarcados bajo los siguientes apartes: •

Adquisición y transformación de los datos desde los sistemas fuentes



Habilitación espacial de la información



Definición y acceso de los Metadatos



Definición de la arquitectura técnica y diseño de la bodega



Proveer un acceso fácil y eficiente de los datos

48

Un proyecto de esta magnitudes tiene muchos desafíos, de tal manera que la metodología debe estar orientada a: •

Enfocar los alcances y requerimientos, creando una arquitectura flexible y capaz de prosperar dinámicamente de acuerdo al ambiente del negocio, brindando una gama de usos impredecibles pero aplicables para los usuarios.



Ser capas de manejar y diluir los diferentes riesgos que se puedan presentar a lo largo de todo el proyecto, en especial en los datos.



Involucrar en cada uno de los procesos y etapas del proyecto a los diferentes usuarios, que sean agente activo del mismo.



Establecer una comunidad enfocada a la cultura geográfica.



Definir la arquitectura técnica de la bodega, de tal manera que integre todos los datos de las diferentes componentes del negocio, y entregue una extensible y escalable solución



Esbozar una aproximación que produzca rápidos e inmediatos beneficios al negocio, como soluciones Data Mart.



Emplear variedad de tecnologías vigentes, estándares y escalables para la variedad de procesos del proyecto.



Colocar claros todos los procesos y tareas del proyecto, así podrá de igual manera entregar objetivos claros y concisos.



Asignar tareas a los procesos, basados en técnicas comunes, habilidades o dependencias.



Asignar procesos a las fases, basado en el desarrollo propuesto para el proyecto, la culminación de cada fase debe reflejar el cumplimiento de un objetivo.

En el proyecto usted debe considerar elementos fundamentales como la buena definición de tareas y actividades desarrolladas por cada una de ellas, las tareas pueden ser definidas por desglosamiento de la estructura del trabajo a lo largo del proyecto o organizadas por procesos y fases. Así como los diferentes papeles que van a desempeñar todas las personas participes del proyecto directa o indirectamente, existes papeles que son comunes en el

49

proyecto y en la infraestructura existente los cuales pueden se agentes participes para aproximar acertadamente las diferentes tareas y de una vez familiarizarlas con la nueva tecnología, ellos son los analistas, administradores de la base de datos, programadores y auditores, para una buena utilización de los recursos. Además existen nuevos papeles que son específicos de la bodega como lo son los arquitectos del Spatial Data Warehouse, arquitectos de los Metadatos, administradores de la calidad de datos, y el administrador de la bodega. Agrupe las tareas afines orientadas a una única disciplina dentro de las diferentes soluciones de la bodega y conceptualmente son lo que se denominara procesos, los cuales pueden estar en todas o algunas de las fases del proyecto. Los procesos que usted puede encontrar en su proyecto son :

Procesos del proyecto Deficiòn de requerimientos del sistema Adquisiciòn de datos Arquitectura Técnica Calidad de Datos Arquitectura de la Bodega Administraciòn de los Metadatos Acceso a los datos Diseño y construcciòn de la base de datos Documentaciòn Prueba Entrenamiento Transiciòn Soporte posterior a la implementaciòn

Fi g. No. 39 Proceso del proyecto.

50



Definición de requerimientos del sistema; dentro de este proceso se debe especificar los alcances, establecer los lineamientos de la implementación de la bodega, definición de áreas tema, determinación de criterios de éxito, recolección de requerimientos de información, identificación de fuentes de datos, producción de modelos lógicos e identificación de estructuras multidimensionales, geográficas y requerimientos de agregación de datos.



Adquisición de datos, se debe realizar un chequeo de enlaces entre los componentes, determinar todas las fuentes de datos, mapear la transformación de los datos, habilitar espacialmente los datos que así lo requieran.



Arquitectura técnica, en este proceso se debe definir la arquitectura inicial de la bodega, determinar si la base de datos será distribuida o centralizada, garant izar una integración exitosa, definir e implementar: la red, la configuración de la plataforma, el ambiente de desarrollo, la plataforma de pruebas, y el ambiente de producción, todo en un contexto geográfico.



Calidad de los datos, se debe evaluar y seleccionar las herramientas, identificar las reglas de limpieza de los datos, crear módulos para el manejo de excepciones y limpieza de los datos y definir toda la estrategia ETT.



Arquitectura del Spatial Data Warehouse, se debe desarrollar y ejecutar los plane s de integración, la estrategia y los procedimientos de calidad de datos, establecer los mecanismos de resolución de conflictos de diseño, tratar el tema del flujo de administración del Spatial Data Warehouse, definir acuerdos sobre el nivel de servicio, y garantizar que la solución es escalable, extensible y flexible.



Administración de los Metadatos, es recomendable una buena recolección de los Metadatos técnicos, del negocio y los geográficos, integrar los Metadatos dispares y definir la estrategia de acceso a los metadatos.



Acceso a los datos, se debe evaluar los diferentes tipos de usuarios, determinar criterios de selección de herramientas, teniendo en cuenta que permitan emplear componentes de SIG embebidos, desarrollar objetos de acceso a los datos, y tratar el tema de administración y monitoreo de acceso de los datos.

51



Diseño y construcción de la base de datos, crear y validar los diseños lógicos y físicos, crear los diseños para el Spatial Data Warehouse, el Data Mart y la metadata, evaluar las estrategias de particionamiento, identificar índices y claves, crear DDLs, implementar los objetos de producción, diseñar y realizar pruebas de volumen.



Documentación, en este proceso se debe desarrollar documentación de alta calidad, entre la que encontramos: documentación técnica y de usuario, guía de referencia de la metadata, documentación para el proceso de desarrollo, y socialización de la información geográfica.



Pruebas, se debe probar los módulos de adquisición de datos y las herramientas, y realizar pruebas de funcionalidad y regresión.



Entrenamiento, desarrollar el plan de entrenamiento, conformar el material, entrenar los usuarios en el uso de las herramientas, en la generación y manipulación de información, y manipulación de contextos geográficos; entrenar al personal técnico en la administración y el mantenimiento del SDWH.



Transición, en este proceso se crea el plan de instalación, se prepara los ambientes de mantenimiento a clientes y de producción, se implementa el flujo de trabajo del administrador de datos, y se publica eL Spatial Data Warehouse en producción.



Soporte posterior a la implementación, evaluar el uso del Spatial Data Warehouse, monitorear y responder a problemas, corregir errores, realizar actividades de afinación y desempeño, y colaborarle al usuario.

Recordemos que el desarrollo del proyecto puede ser incremental o empaquetado conocido como soluciones tipo Data Mart, donde en el primero se realiza para todo el negocio, y el segundo el mas recomendado se desarrolla por áreas del ne gocio las cuales se pueden consolidar al final del ultimo sub. proyecto DM. Independiente al tipo de acercamiento que se desarrolle los procesos y las diferentes fases prevalecen, variando solamente el volumen de trabajo a desarrollar. Tenga presente que si usted desea desarrollar su proyecto implementando Data Mart por áreas como sub. proyectos de la bodega, el modelo, análisis y alcances debe ser global para poder determinar dimensiones comunes entre los diferentes

52

proyectos DM, para no desarrollar tareas dobles y ser consecuente en una unificación final, si no se realiza de esta manera al final cuando se pretenda desarrollar la unificación en la bodega, la misma no lograra conciliar las diferentes áreas, y el proyecto será un fracaso. Una implementación empaquetada puede ser un componente de una solución incremental. Una vez establecidos los diferentes procesos, debemos definir los aspectos que hacen parte del proyecto de la bodega, los cuales denominaremos fases, para este tipo de proyectos podemos esbozar las siguientes fases:

Fases y Procesos del proyecto ESTRATEGIA

ANALISIS

CONSTRUCCION

REVISION Y EVALUACION

TRANSICION A DEFINICION

DISEÑO

LA PRODUCCION

Deficiòn de requerimientos del sistema Adquisiciòn de datos Arquitectura Técnica Calidad de Datos Arquitectura de la Bodega Administraciòn de los Metadatos Acceso a los datos Diseño y construcciòn de la base de datos Documentaciòn Prueba Entrenamiento Transiciòn Soporte posterior a la implementaciòn

Fi g. No. 40 Fases y Proceso del proyecto.



Estrategia, se debe enfocar en los aspectos globales de la solución del Spatial Data Warehouse a nivel de todo el negocio, mantener una sólida fundamentación para el futuro, se debe determinar la estrategia de adquisición de los datos, Administración de la bodega, calidad de los datos , Metadatos y acceso a los datos.



Definición, esta fase consiste realizar un estudio de alcance de alto nivel, identificar áreas para la prueba de los conceptos, identificar las áreas foco, conducir una visión

53

inicial de la arquitectura y de la cultura geográfica, revisar requerimientos de infraestructura, definir factores de éxito y principales restricciones, definir requerimientos de alto nivel del negocio, directrices, usuarios e identificar las fuentes de datos. •

Análisis, esta fase implica enfocarse en el alcance del incremento, crear modelos de datos lógicos, tratar necesidades de adquisición de datos, determinar los ciclos de proceso de datos y estrategias ETT, crear modelos de datos de los sistemas fuente, crear propuestas de diseño de una arquitectura técnica de largo plazo, y crear tempranamente, propuestas para la arquitectura técnica inicial.



Diseño, consiste en diseñar módulos de adquisición de datos y de carga, valida datos, chequear la integridad de los datos, documentar la adquisición en la metadata, definir especificaciones de acceso a los datos e integrarlas con criterios de acceso geográfico a los mismos, seleccionar y comprar las herramientas, diseñar las estructuras físicas de la base de datos, completar la configuración de la plataforma y crear planes, pruebas, guías de usuario, referencias y material de entrenamiento.



Construcción, construir y probar el ETT, crear diseños físicos de la base de datos, instalar e integrar las herramientas de acceso a los datos, construir consultas y reportes en ámbitos geográficos, instalar el repositorio de la metadata, crear planes de pruebas, validar la arquitectura técnica, producir guías del usuario y de operación, y completar el material de entrenamiento.



Transición a la producción, se debe probar la base de datos de producción, realizar pruebas de volumen y esfuerzo, verificar el desempeño contra los objetivos, afinar la base de datos, implementar procedimientos de administración del Spatial Data Warehouse, realizar pruebas de aceptación por parte del usuario, y proveer soporte y realizar evaluación del uso.



Revisión y evaluación, se debe realizar una revisión al plan del proyecto, identificar, dar alcance y planear el siguiente incremento, involucrar a los usuarios.

54

3.1.

ESTRATEGIA DE IMPLEMENTACIÓN

Todos los proyectos requieren un plan a todos los niveles, los diferentes métodos aseguran la adherencia al plan, y todos los proyectos de Spatial Data Warehouse son muy similares a nivel de implementación a los proyectos Data Warehouse. A la hora del proyecto se debe contar con un buen equipo Spatial Data Warehouse, el cual debe comprender una amplia mezcla de habilidades como:

-

Nuevas tecnologías.

-

Nuevos métodos.

-

Nuevas herramientas.

-

Nuevos paradigmas mentales.

Dentro del proyecto existen una serie de roles claves que pueden garantizar el éxito o fracaso del proyecto como lo son:

-

Gerente del proyecto.

-

Analista del negocio.

-

Arquitecto técnico.

-

Diseñador de la base de datos.

-

Especialista en Middleware.

-

Especialista en Sistemas de Información Geográfica.

-

Especialista en herramientas de consulta .

-

Administrador de la base de datos.

-

Especialista en redes.

-

Diseñador de aplicaciones.

Es importante que estos roles no sean exclusividad de la empresa que fue contratada para desarrollar el proyecto, como habíamos mencionado lo recomendado es evaluar que roles

55

existen en otros preámbulos dentro del negocio y que sean ellos los que sean los agentes activos en estas actividades, de igual manera es recomendable que se realice un estudio de los candidatos del negocio a desempeñar los roles faltantes cubiertos por la empresa contratada y ellos sean asistentes de los mismos para que la transición de funciones una vez finalizado la contratación sea optima y se garantice la continuidad de la bodega.

3.1.1. Factores Críticos de Éxito

Las principales claves que permiten una habilitación optima del proyecto están en la administración, la tecnología y los procesos, de igual manera las fases claves son la planeación, implementación y operación de la bodega; y los principales factores críticos de éxito son la metodología, conocimiento del negocio y compromiso, involucrar al usuario final en todos los procesos y fases del proyecto, y tal vez la mas importante es la investigación de requerimientos; sin dejar de lado los servicios de integración de sistemas de consultoría, arquitectura del hardware, herramientas, aspectos operacionales, cultura geográfica, administración del cambio, la definición del piloto, la expansión y los ajustes.

Una consideración que se debe tener es la expansión del numero de los usuarios, si el proyecto es un éxito al inicio de la puesta en marcha no todos los usuarios lo utilizaran, habrán usuarios incrédulos que inicia lmente no lo usaran, pero con la disolución de incertidumbres lo harán cuantificar, prever y siguir detalladamente este fenómeno para que en periodos posteriores a la implementación el sistema siga operando idealmente.

3.1.2. Selección de Herramientas

Usted debe tener los siguientes criterios para definir el hardware y el sistema operativo: -

Características de la arquitectura de hardware como memoria grande, arquitectura escalable y clustering.

-

Benchmark públicos.

56

-

Proveedores, adhesión a los estándares tecnológicos, y compromiso con los sistemas abiertos.

Para la selección de herramientas tenga en cuenta que estas son las que necesita: -

Herramientas de extracción y transformación de datos alfanuméricos y geográficos.

-

Manejo de nombres , direcciones y geocodificación.

-

Calidad de los datos

-

DBMS

-

OLAP

-

Data Mining, acceso y reportes

-

Middleware de acceso de datos, transporte y replicación de datos.

-

Modelamiento de datos.

-

Herramientas tipo SIG.

-

Controles de componentes de SIG embebidos.

Desarrolle un proceso de evaluación rigurosa de las herramientas, es bueno considerar que a nivel de herramientas de Sistemas de Información Geográfica, las compatibles con tecnología COM son las mas robustas, flexibles y escalables, y que para OLAP y Data Mining son las únicas que poseen controles de objetos que permiten embeber la funcionalidad espacial en herramientas estándar para estas tareas. La tecnología ArcGIS de ESRI, se acopla perfectamente y desempeña un excelente papel en la implementación del Spatial Data Warehouse, desde los sistemas OLTP con ArcInfo y ArcView, pasando por todas las tareas ETT, con la tecnología ArcObjects permitiendo desarrollar DDLs ínteroperables para la bodega, una vez en el ODS ArcSDE permite unificar un modelo holístico instantáneo del Spatial Data Warehouse, de tal manera que permita potencializar el DBMS con la geografía del dato no como una representación picto morfológica de un fenómeno de la realidad basada en una colección de coordenadas si no como un objeto geográfico, es decir atenuando las diferencias entre el modelo lógico y el físico, sirviendo de sustento bajo el mismo armazón ArcObject en las herramientas OLAP; y Data Mining, donde las actuales como Discovery o Business Objects permiten SIG embebido a través de ArcObjects.

57

Ambiente operacional de la Empresa

Ambiente de la Bodega

Spatial Data Warehouse

BD OLTP 010101010101010101 010101010101010101 010101010101010101 010101010101010101

ODS

Archivos Planos

Cartografia Existente

Data Marts

Plataforma de Producción

Datos de

Data

Análsis

Mining

Fig. No. 41 Tecnología ArcGIS en el Spatial Data Warehouse.

OLAP

58

ABREVIATURAS

DBMS:

Sistema de Administración de bases de datos (Data Base Manager System)

DM:

Data Mart

DML:

Lenguaje de manipulación de datos.

DSS:

Sistema de soporte de decisiones (Decision support system)

DWH:

Data Warehouse

ETT:

Extracción, Transformación y Transporte

IT:

Tecnología de la Información (Information Technology) system)

ODS:

Operational Data Store, Almacén de Datos Operacionales

OLAP:

Procesamiento analítico en línea (online analytical processing)

OLTP:

Sistemas de procesamiento transaccional en línea. (online transaction processing PGA: Área global de programa

SGA:

Área global de sistema

SI:

Sistemas de Información

SIG:

Sistemas de Información Geográfica

SPDW:

Spatial Data Warehouse

59

LISTA DE GRAFICAS

Gráfica No. 1

Fig. No 1. Esquema de definición del Spatial Data Warehouse

Gráfica No. 2.

Fig. No 2. Ámbito operacional del Data Warehouse

Gráfica No. 3.

Fig. No 3. Sello de tiempo del Data Warehouse

Gráfica No. 4.

Fig. No 4. Esquema de operaciones DML en el DWH

Gráfica No. 5.

Fig. No 5. Esquema de los datos en el Spatial Data Warehouse geográfico

Gráfica No. 6

Fig. No 6. Esquema general del diseño proyecto Spatial Data Warehouse

Gráfica No. 7

Fig. No 7. Procesamiento Transaccional en línea

Gráfica No. 8

Fig. No 8. Proceso de Extracción, Transformación y Transporte de los datos para alimentar la bodega.

Gráfica No. 9

Fig. No 9. Esquema General de alimentación y consultas del Spatial Data Warehouse

Gráfica No. 10

Fig. No 10. Panorama del ODS

Gráfica No. 11

Fig. No 11. Esquema de los Data Marts

Gráfica No. 12

Fig. No 12. Data Mart dependiente

Gráfica No. 13

Fig. No 13. Data Mart independiente

Gráfica No. 14

Fig. No 14. Data Mart híbrido

Gráfica No. 15

Fig. No 15. On-line Analytical Processing OLAP

Gráfica No. 16

Fig. No 16. Servidores OLAP

Gráfica No. 17

Fig. No 17. Base de datos multidimensional

Gráfica No. 18

Fig. No 18. Esquema global del Spatial Data Warehouse

Gráfica No. 19

Fig. No 19. Modelo estrella

Gráfica No. 20

Fig. No 20 Modelamiento de datos

Gráfica No. 21

Fig. No 21. Modelo Estrella

Gráfica No. 22

Fig. No 22. Modelo Copo de nieve

60

Gráfica No. 23

Fig. No 23. Modelo Constelación

Gráfica No. 24

Fig. No 24. Jerarquía de las consultas

Gráfica No. 25

Fig. No 25. Modelando la dimensión tiempo

Gráfica No. 26

Fig. No 26 Modelando la historia del dato

Gráfica No. 27

Fig. No 27. Modelo Corporativo de ejemplo

Gráfica No. 28

Fig. No 28 Primer paso remover datos operacionales

Gráfica No. 29

Fig. No 29. Primer paso modelo corporativo sin datos operacionales

Gráfica No. 30

Fig. No 30. Segundo paso adicionar el elemento tiempo

Gráfica No. 31

Fig. No 31. Tercero paso adicionar datos derivados

Gráfica No. 32

Fig. No 32. Cuarto paso crear relaciones

Gráfica No. 33

Fig. No 33. Quinto paso juntar datos afines

Gráfica No. 34

Fig. No 34. Sexto paso segregar datos(1)

Gráfica No. 35

Fig. No 35. Sexto paso segregar datos(2)

Gráfica No. 36

Fig. No 36. Séptimo paso consolidar la dimensión tiempo

Gráfica No. 37

Fig. No 37. Octavo paso aplicar datos contextuales

Gráfica No. 38

Fig. No 38. Noveno paso sintetice todo el modelo de la bodega

Gráfica No. 39

Fig. No 39. Procesos del proyecto.

Gráfica No. 40

Fig. No 40. Fases y Procesos del proyecto.

Gráfica No. 41

Fig. No 41. Tecnología ArcGIS en el Spatial Data Warehouse

61

GLOSARIO

DATA MART:

Subconjunto de datos de la bodega, extraídos por áreas, para descongestionar las tareas del servidor.

DATA MINING:

(Minería del dato), Metodología de encontrar patrones y relaciones entre los diferentes datos sin intervención humana, o patrones preestablecidos.

DESNORMALIZAR:

Acción de reversar la normalización.

GEOREFERENCIACIÓN:

Proceso de asignación de coordenadas a elemento u objeto de la realidad en una representación picto morfológica que lo represente.

GEOCODIFICAR:

Proceso de asignación de un código natural o de una nomenclatura a una localización geográfica.

HOLISTICA:

Doctrina epistemológica que hace hincapié en el estudio de los elementos desde su totalidad.

JOIN:

Unión lógica empleada en el predicado de una consulta a dos relaciones a través de una llave para devolver una única relación.

NORMALIZAR:

Acción de eliminar la redundancia de datos en una relación para minimizar su almacenamiento.

NEGOCIO:

Ámbito general de la empresa a todos sus niveles.

MULTIDIMENSIONAL:

Modelo compuesto por la dimensionalidad de las diferentes medidas o indicadores de un negocio, donde el cruce de las mismas se desarrolla en una tabla de hechos en donde se indica un evento o acción ocurrida en el negocio.

OLAP:

Procesamiento analítico en línea, consulta basada en conocimientos dados y presunciones.

62

PARADIGMA:

Ejemplo que sirve como patrón, (paradigma en latín, paradeigma en griego)

OLTP:

procesamiento transaccional en línea, es aquel que soporta las operaciones diarias de la empresa.

REPOSITORIO:

Espacio físico dedicado a almacenar bloques de información.

RESERVORIO:

Espacio lógico

dedicado a almacenar bloques de

información SISTEMAS TRANSACCIONALES: Ambiente donde se desarrollan las operaciones tradicionales de inserción, actualización, borrado y consulta de los datos, diarias de la empresa. SOFTWARE:

Componente

lógico

computacional,

que

esta

compuesto por programas y estructuras de lenguaje. TIPO ABSTRACTO DE DATO:

Un tipo abstracto de dato describe una coleccion con la misma estructura y comportamiento.

TOPOLOGÍA:

Modelo

matemático

que

permite

relacionar

espacialmente diferentes geometrías que representan fenómenos en el mundo real.

63

REFERENCIAS

[CARDENAS, 1998] Cárdenas Francisco J. “Principios de Data Warehouse”, Agosto de 1998. [DATE, 1999] C.J. Date, “Introducción a los Sistemas de bases de Datos”, Vol 1. 1997. [ORACLE, 1997] Oracle Corporation, “Data Warehousing Fundamentals”, 1997. [ORACLE, 1999] Oracle Corporation, “Oracle Data Mart Suite Implementation”, Julio de 1999. [ORACLE, 1999] Oracle Corporation, “Data Warehouse Database Design”, Junio de 1999. [ORACLE, 1999] Oracle Corporation, “Database Administration”, Abril de 1999. [ORACLE, 1999] Oracle Press, “Database Design and Object Modeling”, 1999. [ZEILER, 1999] Zeiler Michael ESRI, “Modeling our World” , 1999.