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.
