Aproximación metodológica SDW

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
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.
Orientado a Integrada
ica
temas ráf
og
Ge
Variante en 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:

- 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 .
1
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 Datos Tiempo
Tiempo Geometria
100
101
102
103
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
Geográfia Administración Acceso y Analisis

ETT 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
Base de Datos
Archivos Planos Integradora
(bodega
transitoria) Spatial Data
Warehouse
Cartografia Existente
Plataforma de
Producción 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 Ambiente de la
operacional de la Bodega
Ambiente de la
Empresa
Bodega
BD OLTP
010101010101010101
010101010101010101
010101010101010101
010101010101010101
Base de Datos
Archivos Planos Integradora
(bodega
transitoria) Spatial Data
Warehouse
Plataforma de
Usuarios
Producción Plataforma de
Simples Previsivas OLAP
Producción
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 independiente
OLTP SDWH

Data Mart híbrido
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
acuerdo a las dimensiones accedidas.
n
ció
ica
Ub
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 Ambiente de la
operacional de la Bodega
Empresa Spatial Data
Warehouse
BD OLTP
010101010101010101
010101010101010101
010101010101010101
010101010101010101
ODS
Archivos Planos
Plataforma de
Producción Data Marts
Datos de Data OLAP
Análsis Mining Fig. No. 18
Esquema global del Spatial Data Warehouse
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
Fecha_ID Tabla de Hechos Sector _ID
Año_ID Estrato _ID
Mes _ID Tabla de Hechos Ventas Geometria_ID
Día _ID Tiempo_ID Ubicación _ID
Lugar_ID
Dimensiones
Dimensiones
Cliente_ID
Producto_ID
Unidades
Ventas
Precio
Dimension Cliente Dimension Producto
Costo
Cliente _ID Producto _ID
Margen
Cuenta _ID 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 Logico
Modelo Físico Modelo Físico
Sistemas Bodega
Operacionales Fig. No. 20
Modelamiento de Datos
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 Tienda_ID
Fecha_ID Tabla de Hechos Sector _ID
Año_ID Estrato _ID
Mes _ID Tabla de Hechos Ventas Geometria
Día _ID Tiempo_ID Ubicación_espacial
Lugar_ID
Dimensiones
Dimensiones
Cliente_ID
Producto_ID
Unidades
Ventas
Dimension Cliente Precio

Dimension Producto
Cliente _ID Costo
Producto _ID
Cuenta _ID Margen Item _ID
Envio _ID Familia _ID
Segmento _ID Prod_descripción
Fig. No. 21
Modelo Estrella
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
Tabla de Hechos Geometria Ubicación_espacial
Tabla de Hechos Ventas
Ubicación_espacial
Tiempo_ID
Tienda_ID
Dimensiones
Dimesiones
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 Fig. No. 23
Modelo Constelación
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 Mes_ID
Trimestre_ID Trimestre_ID
Semestre_ID Semestre_ID Trimestre_ID
Año_ID Año_ID
Mes_Fiscal_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
Margen
Dimension Cliente Tabla Historia Cliente

Cliente _ID Cuenta _ID Nombre Estado_civil Version Fecha
Dimesion
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
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
CUENTA_CLIENTE PRODUCTO
º Fecha_creación
#* Cuenta_ID #* Producto_ID
º Descripción * Item_ID
* Creada_por * Familia_ID
SECTOR * 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
- 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
- Descripción * Item_ID
- Creada_por * Familia_ID
SECTOR - Fecha_contrato * Clase_ID
#* Sector_ID - Creado_por
- Descripción
- Sector_Desc
* Estrato_ID
- Estrato_Desc
Fig. No. 28
Primer paso remover datos operacionales
40
Modelo corporativo sin datos operacionales
CLIENTE ITEM_VENTAS
VENTAS
#* Cliente_ID #* Item_Venta_ID
#* Ventas_ID
* Nombre * Precio
* Numero_Orden
* Dirección * Costo
* Fecha
* 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
* Dirección * Costo
+ Fecha_instantanea
* Telefono
+ Fecha_instantanea
TIENDA
#* Tienda_ID
* Geometria_ID
* Ubicación
CUENTA_CLIENTE
+ Fecha_instantanea
PRODUCTO
#* Cuenta_ID
+ Fecha_instantanea #* 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 * Nombre * Precio
+ Precio
+ Costo * Dirección * Costo
+ Margen * Telefono * Fecha_instantanea
* Fecha_instantanea
+ Total_compras
TIENDA
#* Tienda_ID
* Geometria_ID
* Ubicación
* Fecha_instantanea
+ Total_tiendas
* Fecha_instantanea
* 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 * Nombre + Ventas_ID
* Precio
* Costo * Dirección * Precio
* Margen * Telefono * Costo
* Fecha_instantanea * Fecha_instantanea
* Total_compras
TIENDA + Cuenta_ID
#* Tienda_ID
* Geometria_ID
* Ubicación
* Fecha_instantanea
* Total_tiendas
* Fecha_instantanea
* 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 * Nombre * Ventas_ID + Bodega_ID
* Precio
* Costo * Dirección * Precio + Tiempo_orden
* Margen * Telefono * Costo + Agotado
* Fecha_instantanea * Fecha_instantanea + Vendido
* Total_compras + Bodega_ID
TIENDA * Cuenta_ID + Tiempo_orden
#* Tienda_ID + Agotado
* Geometria_ID + Vendido
* Ubicación
* Fecha_instantanea
CUENTA_CLIENTE
* Total_tiendas
#* Cuenta_ID
* Fecha_instantanea PRODUCTO
#* Producto_ID
* Item_ID
SECTOR
* Familia_ID
#* Sector_ID
* Clase_ID
* Estrato_ID
* Fecha_instantanea
* Fecha_instantanea
* Total_Productos
Fig. No. 33
Quinto paso juntar datos afines
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 * Nombre * Ventas_ID
+ Dirección
* Precio
* Costo * Fecha_instantanea + Telefono * Precio
* Margen * Costo
+ Total_compras
* Fecha_instantanea
* Bodega_ID
TIENDA
* Tiempo_orden
#* Tienda_ID * Agotado
* Geometria_ID * Vendido
* Ubicación
* Fecha_instantanea
* Total_tiendas
PRODUCTO HISTORIA_PROD
#* 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
Fig. No. 34
Sexto paso segregar datos(1)
VENTAS Segregar datos (2)

#* Ventas_ID
* Cliente_ID
* Numero_Orden
* Fecha
CLIENTE DETALLE_CLIENTE ITEM_VENTAS
* Total_ventas
* Precio #* Cliente_ID #* Cliente_ID #* Item_Venta_ID
* Costo * Nombre * Ventas_ID
* Dirección
* Margen
* Fecha_instantanea * Telefono * Precio
+ Bodega_ID
* 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
Fig. No. 35
Sexto paso segregar datos(2)
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
CLIENTE DETALLE_CLIENTE
TIEMPO
#* Cliente_ID #* Cliente_ID
+ Tiempo_ID
* Nombre * Dirección
+ Dia_ID
- Fecha_instantanea * Telefono
+ Mes_ID
+ Trimestre_ID * Total_compras
VENTAS
+ Semestre_ID #* Ventas_ID
+ Año_ID * Cliente_ID
* Numero_Orden
* Fecha
* Total_ventas
* Precio
TIENDA
* Costo
#* Tienda_ID * Margen
* Geometria_ID * Bodega_ID
* Ubicación - Tiempo_orden
- Fecha_instantanea * Agotado PRODUCTO HISTORIA_PROD
* Total_tiendas * Vendido #* Producto_ID #* Producto_ID

* Familia_ID * Item_ID
SECTOR
* Clase_ID * Familia_ID
#* Sector_ID
- Fecha_instantanea * Clase_ID
* Estrato_ID
* Total_Productos * Versión
- 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 CLIENTE DETALLE_CLIENTE
#* Cliente_ID #* Cliente_ID
#* Tiempo_ID
* Dia_ID * Nombre * Dirección
* Mes_ID * Telefono
* Trimestre_ID * Total_compras
VENTAS
* Semestre_ID + Edad
#* Ventas_ID
* Año_ID + Sexo
* Cliente_ID
+ Quincena + Estado_civil
* Numero_Orden
+ Temporada * Fecha
* Total_ventas
TIENDA * Precio
* Costo
#* Tienda_ID * Margen
* Geometria_ID * Bodega_ID
* Ubicación * Agotado
* Total_tiendas * Vendido PRODUCTO HISTORIA_PROD
#* Producto_ID #* Producto_ID
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
Mes_ID Telefono
Trimestre_ID Total_compras
VENTAS
Semestre_ID Edad
Ventas_ID
Año_ID Sexo
Cliente_ID
Quincena Estado_civil
Tiempo_ID
Temporada Producto_ID
Tienda_ID
TIENDA Numero_Orden
#* Tienda_ID Fecha
* Geometria_ID Total_ventas
Precio
* Ubicación
Costo
* Total_tiendas Margen PRODUCTO HISTORIA_PROD
Bodega_ID Producto_ID Producto_ID
Agotado Item_ID Fecha_instantanea
SECTOR Familia_ID Item_ID
Vendido
Sector_ID Clase_ID Familia_ID
Estrato_ID Total_Productos Clase_ID
Vigencia Versión
Fig. No. 38
Noveno paso sintetice todo el modelo de la bodega.
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 de la Spatial Data Warehouse

Ambiente
Bodega
operacional de la
Empresa
BD OLTP
010101010101010101
ODS
010101010101010101
010101010101010101
010101010101010101
Archivos Planos
Cartografia Existente Data Marts

Datos de Data OLAP
Plataforma de Análsis Mining
Producción
Fig. No. 41
Tecnología ArcGIS en el Spatial Data Warehouse.
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.

Aproximación metodológica SDW

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Aproximación metodológica SDW

Cargado por

Copyright:

Formatos disponibles

1

APROXIMACIÓN METODOLOGÍCA DE UN SPATIAL DATA

Juan Eulises Bohorquez

APROXIMACIÓN METODOLOGÍCA DE UN SPATIAL DATA WAREHOUSE

APROXIMACIÓN METODOLOGÍCA DE UN SPATIAL DATA WAREHOUSE

En la actualidad los motores de administración de bases de datos, son herramientas de

Teniendo en cuenta las premisas anteriormente mencionadas, los sistemas de información

2. FUNDAMENTOS DE SPATIAL DATA WAREHOUSE

2.1. PANORAMA DEL SPATIAL DATA WAREHOUSE

Un Spatial Data Warehouse es una colección de datos orientados a temas, integrada,

Un simple, completo, y consistente almacenamiento de datos, obtenidos de una variedad de

Un Data Warehouse es una base de datos que:

2.1.1. ORIENTADO A TEMAS

2.1.3. VARIABLE EN EL TIEMPO

El almacenar los datos de manera histórica, es lo que le permite al Data Warehouse

2.1.5. GEOGRAFIA DEL DATO

El Spatial Data Warehouse forma el corazón de un extensivo Sistema de Información

muchos de los cuales no referencian ubicación espacial, a pesar de poseerla

Datos en el Spatial Data Warehouse

Geográfia Administración Acceso y Analisis

áreas de orientación, identificación de flujos operativos y administrativos de los datos,

Fig. No. .7.

En el proyecto uno de los esquemas mas importantes es el de acceso a la bodega, ya que la

2.2. ESQUEMA DEL SPATIAL DATA WAREHOUSE

es guardar el histórico del dato, si no simplemente es una área de organización para la

SDWH Fig. No. 10

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

Data Marts Fig. No. 11

y específicos por departamento es recomendable desarrollar un híbrido entre los

Data Mart Fig. No. 12

Data Mart Fig. No. 13

Data Mart Fig. No. 14

(HOLAP), para poder desarrollar el análisis en línea de lo contrario no seria posible

OLAP Fig. No. 15

Servidores OLAP Fig. No. 16

volumen de datos que se le especifique a recorrer, las herramientas que se utilizan o

Dimension Tiempo Dimension Ubicación

capturados no refrescados. Recordemos que en la normalización se pretende eliminar la

2.3. MODELAMIENTO DE DATOS

Los procesos y etapas que se desarrollan en el modelamiento de los datos de un Spatial

Modelo Logico Modelo Logico

Modelo Físico Modelo Físico

• Modelo conceptual, es un alto nivel de definición de los datos y procesos utilizados

El modelo de datos empresarial es uno de muchos que soporta toda la estrategia de la

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

1. Determinar una estrategia global para la implementación de la bodega, incremental

2.3.1. Spatial data Warehouse modelo estrella

Dimension Tiempo Dimension Tienda

Dimension Cliente Precio

2.3.2. Spatial data Warehouse copo de nieve

Dimension Producto Dimension Tienda Tabla Seccion

2.3.3. Spatial data Warehouse constelación

Dimension Cliente Dimension Tiempo

Dimension Producto Dimension Tienda

En el modelo de la bodega (modelo multidimensional), puede ser tan extenso como se

La ventaja de manejar jerarquías radica en poder analizar de lo general a lo particular lo que

Drill - up Drill - down Fig. No. 24

Tabla de Hechos Tabla de Hechos Tabla de Hechos

Dimension Tiempo Dimension Tiempo Dia_ID

Dimension Cliente Tabla Historia Cliente

1 1 Pepito Pérez Soltero 1 30-06-1996

2.3.4. Del modelo corporativo al modelo Spatial Data Warehouse

SECTOR * Fecha_contrato * Clase_ID