APROXIMACIÓN METODOLOGÍCA DE UN SPATIAL … poblado de la misma a partir de los sistemas...

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 multidimensional 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 solamente 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

temas

Integrada

Variante en

El tiempo

No VolatilGeog

ráfica

Orientado a

temas

Integrada

Variante en

El tiempo

No VolatilGeog

ráfica

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 negocio1.

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 - relacional, 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.

IDID DatosDatos100100101101102102103103

104104104104105105

GeometriaGeometriaTiempoTiempo

Datos en el Spatial Data Warehouse

IDID DatosDatos100100101101102102103103

104104104104105105

GeometriaGeometriaTiempoTiempoIDID DatosDatos100100101101102102103103

104104104104105105

GeometriaGeometriaTiempoTiempo

Datos en el Spatial Data Warehouse

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

ETTAdministración

de los Datos

Acceso y Analisis

de los Datos

Geográfia

De los datos

Diseño y Modelamiento

Metodologia

ETTETTAdministración

de los Datos

Administración

de los Datos

Acceso y Analisis

de los Datos

Acceso y Analisis

de los Datos

Geográfia

De los datos

Geográfia

De los datos

Diseño y Modelamiento

Metodologia

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 mantienen 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

010101010101010101010101010101010101010101010101010101010101010101010101

BD OLTP

Archivos Planos

Cartografia Existente

Base de Datos Integradora

(bodega transitoria)

Plataforma de Producción

Ambiente de la Bodega

Spatial Data Warehouse

010101010101010101010101010101010101010101010101010101010101010101010101

BD OLTP

Archivos Planos


010101010101010101010101010101010101010101010101010101010101010101010101

010101010101010101010101010101010101010101010101010101010101010101010101

BD OLTP

Archivos Planos








Spatial Data WarehouseSpatial Data Warehouse

Fig. No. 8

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

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

finalidad del Spatial Data Warehouse no es simplemente almacenar todos los datos del

14

negocio por áreas, sino la esencia es servir de base para la inferencia y construcción de

información que sustente la toma de decisiones; en la mayoría de textos tradicionales de

bases de datos el termino dato es permutable y equivalente al termino información, pero la

diferencia es sencilla, pongamos dos ejemplos que permiten definir y diseminar claramente

los dos términos, primero se realiza una consulta al repositorio de datos ¿ Cuanto vendí la

semana pasada y en donde?; y la segunda ¿Qué combinación de productos se vendieron

mejor la semana pasada y como están segmentados a lo largo de la ciudad ?, la diferencia es

clara en el primer caso es una simple consulta a un dato en la bodega, y la segunda extrae

información de la misma, combinando en línea distintas variables que determinan el

comportamiento del negocio, mas adelante hablaremos en detalle de este tipo de consultas

que son extraídas con herramientas de procesamiento analítico en línea (OLAP). Una vez

claro los conceptos información y dato, se necesitan un conjunto de herramientas como ya

mencionamos que permitan la extracción de información y la construcción de reportes a

partir de los datos en la bodega, estas herramientas deben ser fáciles de usar, intuitivas,

deben permitir que los usuarios naveguen libremente de lo general a lo particular en los

datos, así como permitir documentar los mismos y de fácil capacitación para uso masivo,

pero recordemos siempre en un ámbito de seguridad y administración estable; se debe

establecer previo a la implementación las dimensiones de los alcances de los

requerimientos de los usuarios, ya sea para adquirir las herramientas que cumplan

cabalmente con los requisitos, construirlas, o simplemente personalizar las adquiridas o

existentes, adicionalmente se debe tener en cuenta que la bodega de datos no es cualquier

base de datos, que su tamaño en muy superior, que la estructura de los datos no es común, y

que la información geográfica no es tabular y que por ende requerimos herramientas tipo

SIG, para que consulten la bodega, visualicen, manipulen y analicen los datos espaciales en

un ambiente topológico, y en esquema cliente / servidor, como lo es el Spatial Data

Warehouse, donde el servidor central mantiene los datos, la administración y la seguridad,

el cliente inicia una transacción con el, realiza una petición de los datos, y una vez el

servidor haya autorizado la transacción y respondido la petición el cliente los analice,

interprete y procese.

15

Ambiente operacional de la

Empresa

010101010101010101

010101010101010101

010101010101010101

010101010101010101

BD OLTP

Archivos Planos







Simples

Consultas

Previsivas OLAP

Usuarios


Empresa

010101010101010101

010101010101010101

010101010101010101

010101010101010101

BD OLTP

Archivos Planos




010101010101010101

010101010101010101

010101010101010101

010101010101010101

BD OLTP

Archivos Planos


010101010101010101

010101010101010101

010101010101010101

010101010101010101

010101010101010101

010101010101010101

010101010101010101

010101010101010101

BD OLTP

Archivos Planos









Simples

Consultas

Previsivas OLAP

Usuarios

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.

OLTP

ODS

SDWH

Analistas del Negocio

OLTP

ODS

SDWH

Negocio

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.

OLTP

ODS

SDWH

Data Marts

OLTP

ODS

SDWH

Data MartsFig. 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

OLTP SDWH

Data Mart Fig. No. 12

Data Mart dependiente

OLTP

Data Mart

OLTP

Data MartFig. No. 13

Data Mart independiente

OLTP SDWH

Data Mart

OLTP SDWH

Data MartFig. No. 14

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

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.

Tiempo

Producto

Ubicaci

ónTiempo

Producto

Ubicaci

ón

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.


Empresa

010101010101010101

010101010101010101010101010101010101

010101010101010101

BD OLTP

Archivos Planos


ODS




OLAPData Marts

Datos de

Análsis

Data

Mining


Empresa

010101010101010101

010101010101010101010101010101010101

010101010101010101

BD OLTP

Archivos Planos


010101010101010101

010101010101010101010101010101010101

010101010101010101

010101010101010101

010101010101010101010101010101010101

010101010101010101

BD OLTP

Archivos Planos


ODSODS




OLAPData Marts

Datos de

Análsis

Data

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.

Tabla de Hechos Ventas

Tiempo_ID

Lugar_ID

Cliente_ID

Producto_ID

Unidades

Ventas

Precio

Costo

Margen

Dimension Tiempo

Tiempo_ID

Fecha_ID

Año_ID

Mes _ID

Día _ID

Dimension Ubicación

Lugar_ID

Sector _ID

Estrato _ID

Geometria_ID

Ubicación _ID

Dimension Producto

Producto _ID

Item _ID

Familia _ID

Clase _ID

Dimension Cliente

Cliente _ID

Cuenta _ID

Envio _ID

Segmento _ID

Tabla de Hechos

Dim

ensi

ones

Dim

ensiones


Tiempo_ID

Lugar_ID

Cliente_ID

Producto_ID

Unidades

Ventas

Precio

Costo

Margen

Dimension Tiempo

Tiempo_ID

Fecha_ID

Año_ID

Mes _ID

Día _ID


Lugar_ID

Sector _ID

Estrato _ID

Geometria_ID

Ubicación _ID

Dimension Producto

Producto _ID

Item _ID

Familia _ID

Clase _ID

Dimension Cliente

Cliente _ID

Cuenta _ID

Envio _ID

Segmento _ID


Tiempo_ID

Lugar_ID

Cliente_ID

Producto_ID

Unidades

Ventas

Precio

Costo

Margen

Dimension Tiempo

Tiempo_ID

Fecha_ID

Año_ID

Mes _ID

Día _ID


Lugar_ID

Sector _ID

Estrato _ID

Geometria_ID

Ubicación _ID

Dimension Producto

Producto _ID

Item _ID

Familia _ID

Clase _ID

Dimension Cliente

Cliente _ID

Cuenta _ID

Envio _ID

Segmento _ID

Tabla de Hechos

Dim

ensi

ones

Dim

ensiones

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 ambiente 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

Operacionales

Bodega

Modelo Conceptual



Modelo Conceptual



Sistemas

Operacionales

Bodega

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


Tiempo_ID

Lugar_ID

Cliente_ID

Producto_ID

Unidades

Ventas

Precio

Costo

Margen

Dimension Tiempo

Tiempo_ID

Fecha_ID

Año_ID

Mes _ID

Día _ID

Dimension Tienda

Tienda_ID

Sector _ID

Estrato _ID

Geometria

Ubicación_espacial

Dimension Producto

Producto _ID

Item _ID

Familia _ID

Prod_descripción

Dimension Cliente

Cliente _ID

Cuenta _ID

Envio _ID

Segmento _ID

Tabla de Hechos

Dim

ensi

ones

Dim

ensiones


Tiempo_ID

Lugar_ID

Cliente_ID

Producto_ID

Unidades

Ventas

Precio

Costo

Margen

Dimension Tiempo

Tiempo_ID

Fecha_ID

Año_ID

Mes _ID

Día _ID

Dimension Tienda

Tienda_ID

Sector _ID

Estrato _ID

Geometria

Ubicación_espacial

Dimension Producto

Producto _ID

Item _ID

Familia _ID

Prod_descripción

Dimension Cliente

Cliente _ID

Cuenta _ID

Envio _ID

Segmento _ID

Tabla de Hechos

Dim

ensi

ones

Dim

ensiones

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


Tiempo_ID

Tienda_ID

Cliente_ID

Producto_ID

Unidades

Ventas

Precio

Costo

Margen

Dimension Tiempo

Tiempo_ID

Semana_ID

Periodo_ID

Año _ID

Dimension Tienda

Tienda_ID

Tienda_desc

Sección_id

Geometria

Ubicación_espacial

Dimension Producto

Producto _ID

Prod_descripción

Dimension Cliente

Cliente _ID

Cliente_desc

Cuenta _ID

Tabla de Hechos

Dim

esio

nes Dimensiones

Tabla Seccion

Seccion_ID

Seccion_desc

Geometria

Ubicación_espacial

Tabla Cuenta

Cuenta _ID

Cuenta_desc

Segmento _ID

Tabla Segmento

Segmento _ID

Segmento_nombre

Segmento_desc


Tiempo_ID

Tienda_ID

Cliente_ID

Producto_ID

Unidades

Ventas

Precio

Costo

Margen

Dimension Tiempo

Tiempo_ID

Semana_ID

Periodo_ID

Año _ID

Dimension Tienda

Tienda_ID

Tienda_desc

Sección_id

Geometria

Ubicación_espacial

Dimension Producto

Producto _ID

Prod_descripción

Dimension Cliente

Cliente _ID

Cliente_desc

Cuenta _ID

Tabla de Hechos

Dim

esio

nes Dimensiones

Tabla Seccion

Seccion_ID

Seccion_desc

Geometria

Ubicación_espacial

Tabla Cuenta

Cuenta _ID

Cuenta_desc

Segmento _ID

Tabla Segmento

Segmento _ID

Segmento_nombre

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 dimensiones , 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 Tiempo

Dimension TiendaDimension Producto

Dimension Cliente

Tablas de Hechos

Dimensiones

Dimensiones


Unidades

Ventas

Precio

Costo

Tabla Hechos Ventas Sumarizadas

Sum_Promedio_unidades

Sum_Promedio_ventas

Sum_Promedio_precio

Sum_Promedio_costo

Dimension Tiempo

Dimension TiendaDimension Producto

Dimension Cliente

Tablas de Hechos

Dimensiones

Dimensiones


Unidades

Ventas

Precio

Costo


Unidades

Ventas

Precio

Costo



Sum_Promedio_ventas

Sum_Promedio_precio

Sum_Promedio_costo



Sum_Promedio_ventas

Sum_Promedio_precio

Sum_Promedio_costo

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 - downDrill - up Drill - downDrill - up 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

Dia_ID

Dimension Tiempo

Dia_ID

Mes_ID

Trimestre_ID

Semestre_ID

Año_ID

Tabla de Hechos

Dia_ID

Dimension Tiempo

Dia_ID

Mes_ID

Trimestre_ID

Semestre_ID

Año_ID

Mes_Fiscal_ID

Trimestre_ fiscal_ID

Semestre_fiscal_ID

Año_ fiscal _ID

Dia_ID

Tabla de Hechos

Dia_ID

Mes_ID

Trimestre_ID

Semestre_ID

Año_ID

Tabla de Hechos

Dia_ID

Dimension Tiempo

Dia_ID

Mes_ID

Trimestre_ID

Semestre_ID

Año_ID

Tabla de Hechos

Dia_ID

Dimension Tiempo

Dia_ID

Mes_ID

Trimestre_ID

Semestre_ID

Año_ID

Tabla de Hechos

Dia_ID

Dimension Tiempo

Dia_ID

Mes_ID

Trimestre_ID

Semestre_ID

Año_ID

Mes_Fiscal_ID


Semestre_fiscal_ID

Año_ fiscal _ID

Tabla de Hechos

Dia_ID

Dimension Tiempo

Dia_ID

Mes_ID

Trimestre_ID

Semestre_ID

Año_ID

Mes_Fiscal_ID


Semestre_fiscal_ID

Año_ fiscal _ID

Dia_ID

Tabla de Hechos

Dia_ID

Mes_ID

Trimestre_ID

Semestre_ID

Año_ID

Dia_ID

Tabla de Hechos

Dia_ID

Tabla de Hechos

Dia_ID

Mes_IDMes_ID

Trimestre_IDTrimestre_ID

Semestre_IDSemestre_ID

Año_IDAño_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.


Tiempo_ID

Tienda_ID

Cliente_ID

Producto_ID

Unidades

Ventas

Precio

Costo

Margen

Tabla de Hechos

Dim

esio

n

Dimension Cliente

Cliente _ID

1

2

3

Tabla Historia Cliente

Cuenta _ID Nombre Estado_civil Version Fecha

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

1 Pepito Pérez Casado 2 30-06-2000

2 Xxxxx Yxxxx Soltero 1 30-06-1996

3 Zzzzzz Www Soltero 1 30-06-1996


Tiempo_ID

Tienda_ID

Cliente_ID

Producto_ID

Unidades

Ventas

Precio

Costo

Margen

Tabla de Hechos

Dim

esio

n

Dimension Cliente

Cliente _ID

1

2

3






3 Zzzzzz Www Soltero 1 30-06-1996

Dimension Cliente

Cliente _ID

1

2

3






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

VENTAS

#* Ventas_ID

* Numero_Orden

* Fecha

º Comentarios

º Asignación

CLIENTE

#* Cliente_ID

* Nombre

* Dirección

* Telefono

* Creado_por

* Credito_ver_por

* Empleado_ver_ID

ITEM_VENTAS

#* Item_Venta_ID

* Precio

* Costo

º Comentarios

º Descripcion

PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID

* Clase_ID

* Creado_por

* Descripción

CUENTA_CLIENTE

#* Cuenta_ID

º Descripción

* Creada_por

* Fecha_contrato

TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

º Descripción

º Fecha_creación

SECTOR

#* Sector_ID

* Sector_Desc

* Estrato_ID

* Estrato_Desc

VENTAS

#* Ventas_ID

* Numero_Orden

* Fecha

º Comentarios

º Asignación

VENTAS

#* Ventas_ID

* Numero_Orden

* Fecha

º Comentarios

º Asignación

CLIENTE

#* Cliente_ID

* Nombre

* Dirección

* Telefono

* Creado_por

* Credito_ver_por

* Empleado_ver_ID

CLIENTE

#* Cliente_ID

* Nombre

* Dirección

* Telefono

* Creado_por

* Credito_ver_por

* Empleado_ver_ID

ITEM_VENTAS

#* Item_Venta_ID

* Precio

* Costo

º Comentarios

º Descripcion

ITEM_VENTAS

#* Item_Venta_ID

* Precio

* Costo

º Comentarios

º Descripcion

PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID

* Clase_ID

* Creado_por

* Descripción

PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID

* Clase_ID

* Creado_por

* Descripción

CUENTA_CLIENTE

#* Cuenta_ID

º Descripción

* Creada_por

* Fecha_contrato

CUENTA_CLIENTE

#* Cuenta_ID

º Descripción

* Creada_por

* Fecha_contrato

TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

º Descripción

º Fecha_creación

TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

º Descripción

º Fecha_creación

SECTOR

#* Sector_ID

* Sector_Desc

* Estrato_ID

* Estrato_Desc

SECTOR

#* Sector_ID

* Sector_Desc

* Estrato_ID

* Estrato_Desc

Modelo corporativo

Fig. No. 27

Modelo Corporativo de ejemplo

VENTAS

#* Ventas_ID

* Numero_Orden

* Fecha

- Comentarios

- Asignación

CLIENTE

#* Cliente_ID

* Nombre

* Dirección

* Telefono

- Creado_por

- Credito_ver_por

- Empleado_ver_ID

ITEM_VENTAS

#* Item_Venta_ID

* Precio

* Costo

- Comentarios

- Descripcion

PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID

* Clase_ID

- Creado_por

- Descripción

CUENTA_CLIENTE

#* Cuenta_ID

- Descripción

- Creada_por

- Fecha_contrato

TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

- Descripción

- Fecha_creación

SECTOR

#* Sector_ID

- Sector_Desc

* Estrato_ID

- Estrato_Desc

VENTAS

#* Ventas_ID

* Numero_Orden

* Fecha

- Comentarios

- Asignación

VENTAS

#* Ventas_ID

* Numero_Orden

* Fecha

- Comentarios

- Asignación

CLIENTE

#* Cliente_ID

* Nombre

* Dirección

* Telefono

- Creado_por

- Credito_ver_por

- Empleado_ver_ID

CLIENTE

#* Cliente_ID

* Nombre

* Dirección

* Telefono

- Creado_por

- Credito_ver_por

- Empleado_ver_ID

ITEM_VENTAS

#* Item_Venta_ID

* Precio

* Costo

- Comentarios

- Descripcion

ITEM_VENTAS

#* Item_Venta_ID

* Precio

* Costo

- Comentarios

- Descripcion

PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID

* Clase_ID

- Creado_por

- Descripción

PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID

* Clase_ID

- Creado_por

- Descripción

CUENTA_CLIENTE

#* Cuenta_ID

- Descripción

- Creada_por

- Fecha_contrato

CUENTA_CLIENTE

#* Cuenta_ID

- Descripción

- Creada_por

- Fecha_contrato

TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

- Descripción

- Fecha_creación

TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

- Descripción

- Fecha_creación

SECTOR

#* Sector_ID

- Sector_Desc

* Estrato_ID

- Estrato_Desc

SECTOR

#* Sector_ID

- Sector_Desc

* Estrato_ID

- Estrato_Desc

Remover Datos operacionales

Fig. No. 28

Primer paso remover datos operacionales

40

VENTAS

#* Ventas_ID

* Numero_Orden

* Fecha

CLIENTE

#* Cliente_ID

* Nombre

* Dirección

* Telefono

ITEM_VENTAS

#* Item_Venta_ID

* Precio

* Costo

PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID

* Clase_ID

CUENTA_CLIENTE

#* Cuenta_ID

TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

SECTOR

#* Sector_ID

* Estrato_ID

VENTAS

#* Ventas_ID

* Numero_Orden

* Fecha

VENTAS

#* Ventas_ID

* Numero_Orden

* Fecha

CLIENTE

#* Cliente_ID

* Nombre

* Dirección

* Telefono

CLIENTE

#* Cliente_ID

* Nombre

* Dirección

* Telefono

ITEM_VENTAS

#* Item_Venta_ID

* Precio

* Costo

ITEM_VENTAS

#* Item_Venta_ID

* Precio

* Costo

PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID

* Clase_ID

PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID

* Clase_ID

CUENTA_CLIENTE

#* Cuenta_ID

CUENTA_CLIENTE

#* Cuenta_ID

TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

SECTOR

#* Sector_ID

* Estrato_ID

SECTOR

#* Sector_ID

* Estrato_ID

Modelo corporativo sin datos operacionales

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.

VENTAS

#* Ventas_ID

* Numero_Orden

* Fecha

CLIENTE

#* Cliente_ID

* Nombre

* Dirección

* Telefono

+ Fecha_instantanea

ITEM_VENTAS

#* Item_Venta_ID

* Precio

* Costo+ Fecha_instantanea

PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID

* Clase_ID+ Fecha_instantanea

CUENTA_CLIENTE

#* Cuenta_ID+ Fecha_instantanea

TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación+ Fecha_instantanea

SECTOR

#* Sector_ID

* Estrato_ID

+ Fecha_instantanea

VENTAS

#* Ventas_ID

* Numero_Orden

* Fecha

VENTAS

#* Ventas_ID

* Numero_Orden

* Fecha

CLIENTE

#* Cliente_ID

* Nombre

* Dirección

* Telefono

+ Fecha_instantanea

CLIENTE

#* Cliente_ID

* Nombre

* Dirección

* Telefono

+ Fecha_instantanea

ITEM_VENTAS

#* Item_Venta_ID

* Precio


ITEM_VENTAS

#* Item_Venta_ID

* Precio


PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID


PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID


CUENTA_CLIENTE


CUENTA_CLIENTE


TIENDA

#* Tienda_ID

* Geometria_ID


TIENDA

#* Tienda_ID

* Geometria_ID


SECTOR

#* Sector_ID

* Estrato_ID

+ Fecha_instantanea

SECTOR

#* Sector_ID

* Estrato_ID

+ Fecha_instantanea

Adicionar el tiempo

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.

VENTAS

#* Ventas_ID

* Numero_Orden

* Fecha

+ Total_ventas+ Precio+ Costo+ Margen

CLIENTE

#* Cliente_ID

* Nombre

* Dirección

* Telefono

* Fecha_instantanea

+ Total_compras

ITEM_VENTAS

#* Item_Venta_ID

* Precio

* Costo

* Fecha_instantanea

PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID

* Clase_ID

* Fecha_instantanea

+ Total_Productos

CUENTA_CLIENTE

#* Cuenta_ID* Fecha_instantanea

TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

* Fecha_instantanea

+ Total_tiendas

SECTOR

#* Sector_ID

* Estrato_ID

* Fecha_instantanea

VENTAS

#* Ventas_ID

* Numero_Orden

* Fecha


VENTAS

#* Ventas_ID

* Numero_Orden

* Fecha


CLIENTE

#* Cliente_ID

* Nombre

* Dirección

* Telefono

* Fecha_instantanea

+ Total_compras

CLIENTE

#* Cliente_ID

* Nombre

* Dirección

* Telefono

* Fecha_instantanea

+ Total_compras

ITEM_VENTAS

#* Item_Venta_ID

* Precio

* Costo

* Fecha_instantanea

ITEM_VENTAS

#* Item_Venta_ID

* Precio

* Costo

* Fecha_instantanea

PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID

* Clase_ID

* Fecha_instantanea

+ Total_Productos

PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID

* Clase_ID

* Fecha_instantanea

+ Total_Productos

CUENTA_CLIENTE


CUENTA_CLIENTE


TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

* Fecha_instantanea

+ Total_tiendas

TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

* Fecha_instantanea

+ Total_tiendas

SECTOR

#* Sector_ID

* Estrato_ID

* Fecha_instantanea

SECTOR

#* Sector_ID

* Estrato_ID

* Fecha_instantanea

Adicionar datos derivados

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

#* Ventas_ID

+ Cliente_ID

* Numero_Orden

* Fecha

* Total_ventas* Precio* Costo* Margen

CLIENTE

#* Cliente_ID

* Nombre

* Dirección

* Telefono

* Fecha_instantanea

* Total_compras

+ Cuenta_ID

ITEM_VENTAS

#* Item_Venta_ID

+ Ventas_ID

* Precio

* Costo

* Fecha_instantanea

PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID

* Clase_ID

* Fecha_instantanea

* Total_Productos

CUENTA_CLIENTE


TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

* Fecha_instantanea

* Total_tiendas

SECTOR

#* Sector_ID

* Estrato_ID

* Fecha_instantanea

VENTAS

#* Ventas_ID

+ Cliente_ID

* Numero_Orden

* Fecha


VENTAS

#* Ventas_ID

+ Cliente_ID

* Numero_Orden

* Fecha


CLIENTE

#* Cliente_ID

* Nombre

* Dirección

* Telefono

* Fecha_instantanea

* Total_compras

+ Cuenta_ID

CLIENTE

#* Cliente_ID

* Nombre

* Dirección

* Telefono

* Fecha_instantanea

* Total_compras

+ Cuenta_ID

ITEM_VENTAS

#* Item_Venta_ID

+ Ventas_ID

* Precio

* Costo

* Fecha_instantanea

ITEM_VENTAS

#* Item_Venta_ID

+ Ventas_ID

* Precio

* Costo

* Fecha_instantanea

PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID

* Clase_ID

* Fecha_instantanea

* Total_Productos

PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID

* Clase_ID

* Fecha_instantanea

* Total_Productos

CUENTA_CLIENTE


CUENTA_CLIENTE


TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

* Fecha_instantanea

* Total_tiendas

TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

* Fecha_instantanea

* Total_tiendas

SECTOR

#* Sector_ID

* Estrato_ID

* Fecha_instantanea

SECTOR

#* Sector_ID

* Estrato_ID

* Fecha_instantanea

Crear relaciones

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.

Juntar datos AfinesVENTAS

#* Ventas_ID

* Cliente_ID

* Numero_Orden

* Fecha


CLIENTE

#* Cliente_ID

* Nombre

* Dirección

* Telefono

* Fecha_instantanea

* Total_compras

* Cuenta_ID

ITEM_VENTAS

#* Item_Venta_ID

* Ventas_ID

* Precio

* Costo

* Fecha_instantanea

+ Bodega_ID

+ Tiempo_orden

+ Agotado

+ Vendido

PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID

* Clase_ID

* Fecha_instantanea

* Total_Productos

CUENTA_CLIENTE


TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

* Fecha_instantanea

* Total_tiendas

SECTOR

#* Sector_ID

* Estrato_ID

* Fecha_instantanea

ITEM_INVENTARIO

+ Producto_ID

+ Bodega_ID

+ Tiempo_orden

+ Agotado

+ Vendido

VENTAS

#* Ventas_ID

* Cliente_ID

* Numero_Orden

* Fecha


VENTAS

#* Ventas_ID

* Cliente_ID

* Numero_Orden

* Fecha


CLIENTE

#* Cliente_ID

* Nombre

* Dirección

* Telefono

* Fecha_instantanea

* Total_compras

* Cuenta_ID

CLIENTE

#* Cliente_ID

* Nombre

* Dirección

* Telefono

* Fecha_instantanea

* Total_compras

* Cuenta_ID

ITEM_VENTAS

#* Item_Venta_ID

* Ventas_ID

* Precio

* Costo

* Fecha_instantanea

+ Bodega_ID

+ Tiempo_orden

+ Agotado

+ Vendido

ITEM_VENTAS

#* Item_Venta_ID

* Ventas_ID

* Precio

* Costo

* Fecha_instantanea

+ Bodega_ID

+ Tiempo_orden

+ Agotado

+ Vendido

PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID

* Clase_ID

* Fecha_instantanea

* Total_Productos

PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID

* Clase_ID

* Fecha_instantanea

* Total_Productos

CUENTA_CLIENTE


CUENTA_CLIENTE


TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

* Fecha_instantanea

* Total_tiendas

TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

* Fecha_instantanea

* Total_tiendas

SECTOR

#* Sector_ID

* Estrato_ID

* Fecha_instantanea

SECTOR

#* Sector_ID

* Estrato_ID

* Fecha_instantanea

ITEM_INVENTARIO

+ Producto_ID

+ Bodega_ID

+ Tiempo_orden

+ Agotado

+ Vendido

ITEM_INVENTARIO

+ Producto_ID

+ Bodega_ID

+ Tiempo_orden

+ Agotado

+ Vendido

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.

Segregar datos (1)VENTAS

#* Ventas_ID

* Cliente_ID

* Numero_Orden

* Fecha


CLIENTE

#* Cliente_ID

* Nombre

* Fecha_instantanea

ITEM_VENTAS

#* Item_Venta_ID

* Ventas_ID

* Precio

* Costo

* Fecha_instantanea

* Bodega_ID

* Tiempo_orden

* Agotado

* Vendido

PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID

* Clase_ID

* Fecha_instantanea

* Total_Productos

TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

* Fecha_instantanea

* Total_tiendas

SECTOR

#* Sector_ID

* Estrato_ID

* Fecha_instantanea

DETALLE_CLIENTE

+ Cliente_ID

+ Dirección

+ Telefono

+ Total_compras

HISTORIA_PROD

+ Producto_ID

+ Fecha_instantanea

+ Item_ID

+ Familia_ID

+ Clase_ID

+ Versión

VENTAS

#* Ventas_ID

* Cliente_ID

* Numero_Orden

* Fecha


VENTAS

#* Ventas_ID

* Cliente_ID

* Numero_Orden

* Fecha


CLIENTE

#* Cliente_ID

* Nombre

* Fecha_instantanea

CLIENTE

#* Cliente_ID

* Nombre

* Fecha_instantanea

ITEM_VENTAS

#* Item_Venta_ID

* Ventas_ID

* Precio

* Costo

* Fecha_instantanea

* Bodega_ID

* Tiempo_orden

* Agotado

* Vendido

ITEM_VENTAS

#* Item_Venta_ID

* Ventas_ID

* Precio

* Costo

* Fecha_instantanea

* Bodega_ID

* Tiempo_orden

* Agotado

* Vendido

PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID

* Clase_ID

* Fecha_instantanea

* Total_Productos

PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID

* Clase_ID

* Fecha_instantanea

* Total_Productos

TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

* Fecha_instantanea

* Total_tiendas

TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

* Fecha_instantanea

* Total_tiendas

SECTOR

#* Sector_ID

* Estrato_ID

* Fecha_instantanea

SECTOR

#* Sector_ID

* Estrato_ID

* Fecha_instantanea

DETALLE_CLIENTE

+ Cliente_ID

+ Dirección

+ Telefono

+ Total_compras

DETALLE_CLIENTE

+ Cliente_ID

+ Dirección

+ Telefono

+ Total_compras

HISTORIA_PROD

+ Producto_ID

+ Fecha_instantanea

+ Item_ID

+ Familia_ID

+ Clase_ID

+ Versión

HISTORIA_PROD

+ Producto_ID

+ Fecha_instantanea

+ Item_ID

+ Familia_ID

+ Clase_ID

+ Versión Fig. No. 34

Sexto paso segregar datos(1)

Segregar datos (2)

CLIENTE

#* Cliente_ID

* Nombre

* Fecha_instantanea

ITEM_VENTAS

#* Item_Venta_ID

* Ventas_ID

* Precio

* Costo

* Fecha_instantanea

* Bodega_ID

* Tiempo_orden

* Agotado

* Vendido

PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID

* Clase_ID

* Fecha_instantanea

* Total_Productos

TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

* Fecha_instantanea

* Total_tiendas

SECTOR

#* Sector_ID

* Estrato_ID

* Fecha_instantanea

VENTAS

#* Ventas_ID

* Cliente_ID

* Numero_Orden

* Fecha


+ Bodega_ID

+ Tiempo_odern

+ Agotado

+ Vendido

DETALLE_CLIENTE

#* Cliente_ID

* Dirección

* Telefono

* Total_compras

HISTORIA_PROD

#* Producto_ID

* Fecha_instantanea

* Item_ID

* Familia_ID

* Clase_ID

* Versión

CLIENTE

#* Cliente_ID

* Nombre

* Fecha_instantanea

CLIENTE

#* Cliente_ID

* Nombre

* Fecha_instantanea

ITEM_VENTAS

#* Item_Venta_ID

* Ventas_ID

* Precio

* Costo

* Fecha_instantanea

* Bodega_ID

* Tiempo_orden

* Agotado

* Vendido

ITEM_VENTAS

#* Item_Venta_ID

* Ventas_ID

* Precio

* Costo

* Fecha_instantanea

* Bodega_ID

* Tiempo_orden

* Agotado

* Vendido

PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID

* Clase_ID

* Fecha_instantanea

* Total_Productos

PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID

* Clase_ID

* Fecha_instantanea

* Total_Productos

TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

* Fecha_instantanea

* Total_tiendas

TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

* Fecha_instantanea

* Total_tiendas

SECTOR

#* Sector_ID

* Estrato_ID

* Fecha_instantanea

SECTOR

#* Sector_ID

* Estrato_ID

* Fecha_instantanea

VENTAS

#* Ventas_ID

* Cliente_ID

* Numero_Orden

* Fecha


+ Bodega_ID

+ Tiempo_odern

+ Agotado

+ Vendido

VENTAS

#* Ventas_ID

* Cliente_ID

* Numero_Orden

* Fecha


+ Bodega_ID

+ Tiempo_odern

+ Agotado

+ Vendido

DETALLE_CLIENTE

#* Cliente_ID

* Dirección

* Telefono

* Total_compras

DETALLE_CLIENTE

#* Cliente_ID

* Dirección

* Telefono

* Total_compras

HISTORIA_PROD

#* Producto_ID

* Fecha_instantanea

* Item_ID

* Familia_ID

* Clase_ID

* Versión

HISTORIA_PROD

#* Producto_ID

* Fecha_instantanea

* Item_ID

* Familia_ID

* Clase_ID

* 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

VENTAS

#* Ventas_ID

* Cliente_ID

* Numero_Orden

* Fecha


* Bodega_ID

- Tiempo_orden

* Agotado

* Vendido

CLIENTE

#* Cliente_ID

* Nombre

- Fecha_instantanea

PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID

* Clase_ID

- Fecha_instantanea

* Total_Productos

TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

- Fecha_instantanea

* Total_tiendas

SECTOR

#* Sector_ID

* Estrato_ID

- Fecha_instantanea

DETALLE_CLIENTE

#* Cliente_ID

* Dirección

* Telefono

* Total_compras

HISTORIA_PROD

#* Producto_ID

* Fecha_instantanea

* Item_ID

* Familia_ID

* Clase_ID

* Versión

TIEMPO

+ Tiempo_ID

+ Dia_ID

+ Mes_ID

+ Trimestre_ID

+ Semestre_ID

+ Año_ID

VENTAS

#* Ventas_ID

* Cliente_ID

* Numero_Orden

* Fecha


* Bodega_ID

- Tiempo_orden

* Agotado

* Vendido

CLIENTE

#* Cliente_ID

* Nombre

- Fecha_instantanea

PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID

* Clase_ID

- Fecha_instantanea

* Total_Productos

TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

- Fecha_instantanea

* Total_tiendas

SECTOR

#* Sector_ID

* Estrato_ID

- Fecha_instantanea

DETALLE_CLIENTE

#* Cliente_ID

* Dirección

* Telefono

* Total_compras

HISTORIA_PROD

#* Producto_ID

* Fecha_instantanea

* Item_ID

* Familia_ID

* Clase_ID

* Versión

TIEMPO

+ Tiempo_ID

+ Dia_ID

+ Mes_ID

+ Trimestre_ID

+ Semestre_ID

+ Año_ID

VENTAS

#* Ventas_ID

* Cliente_ID

* Numero_Orden

* Fecha


* Bodega_ID

- Tiempo_orden

* Agotado

* Vendido

VENTAS

#* Ventas_ID

* Cliente_ID

* Numero_Orden

* Fecha


* Bodega_ID

- Tiempo_orden

* Agotado

* Vendido

CLIENTE

#* Cliente_ID

* Nombre

- Fecha_instantanea

CLIENTE

#* Cliente_ID

* Nombre

- Fecha_instantanea

PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID

* Clase_ID

- Fecha_instantanea

* Total_Productos

PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID

* Clase_ID

- Fecha_instantanea

* Total_Productos

TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

- Fecha_instantanea

* Total_tiendas

TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

- Fecha_instantanea

* Total_tiendas

SECTOR

#* Sector_ID

* Estrato_ID

- Fecha_instantanea

SECTOR

#* Sector_ID

* Estrato_ID

- Fecha_instantanea

DETALLE_CLIENTE

#* Cliente_ID

* Dirección

* Telefono

* Total_compras

DETALLE_CLIENTE

#* Cliente_ID

* Dirección

* Telefono

* Total_compras

HISTORIA_PROD

#* Producto_ID

* Fecha_instantanea

* Item_ID

* Familia_ID

* Clase_ID

* Versión

HISTORIA_PROD

#* Producto_ID

* Fecha_instantanea

* Item_ID

* Familia_ID

* Clase_ID

* Versión

TIEMPO

+ Tiempo_ID

+ Dia_ID

+ Mes_ID

+ Trimestre_ID

+ Semestre_ID

+ Año_ID

TIEMPO

+ Tiempo_ID

+ Dia_ID

+ Mes_ID

+ Trimestre_ID

+ Semestre_ID

+ Año_ID

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 contextualesDETALLE_CLIENTE

#* Cliente_ID

* Dirección

* Telefono

* Total_compras

+ Edad

+ Sexo

+ Estado_civil

VENTAS

#* Ventas_ID

* Cliente_ID

* Numero_Orden

* Fecha


* Bodega_ID

* Agotado

* Vendido

CLIENTE

#* Cliente_ID

* Nombre

PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID

* Clase_ID

* Total_Productos

TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

* Total_tiendas

SECTOR

#* Sector_ID

* Estrato_ID

+ Vigencia

HISTORIA_PROD

#* Producto_ID

* Fecha_instantanea

* Item_ID

* Familia_ID

* Clase_ID

* Versión

TIEMPO

#* Tiempo_ID

* Dia_ID

* Mes_ID

* Trimestre_ID

* Semestre_ID

* Año_ID

+ Quincena

+ Temporada

DETALLE_CLIENTE

#* Cliente_ID

* Dirección

* Telefono

* Total_compras

+ Edad

+ Sexo

+ Estado_civil

DETALLE_CLIENTE

#* Cliente_ID

* Dirección

* Telefono

* Total_compras

+ Edad

+ Sexo

+ Estado_civil

VENTAS

#* Ventas_ID

* Cliente_ID

* Numero_Orden

* Fecha


* Bodega_ID

* Agotado

* Vendido

VENTAS

#* Ventas_ID

* Cliente_ID

* Numero_Orden

* Fecha


* Bodega_ID

* Agotado

* Vendido

CLIENTE

#* Cliente_ID

* Nombre

CLIENTE

#* Cliente_ID

* Nombre

PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID

* Clase_ID

* Total_Productos

PRODUCTO

#* Producto_ID

* Item_ID

* Familia_ID

* Clase_ID

* Total_Productos

TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

* Total_tiendas

TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

* Total_tiendas

SECTOR

#* Sector_ID

* Estrato_ID

+ Vigencia

SECTOR

#* Sector_ID

* Estrato_ID

+ Vigencia

HISTORIA_PROD

#* Producto_ID

* Fecha_instantanea

* Item_ID

* Familia_ID

* Clase_ID

* Versión

HISTORIA_PROD

#* Producto_ID

* Fecha_instantanea

* Item_ID

* Familia_ID

* Clase_ID

* Versión

TIEMPO

#* Tiempo_ID

* Dia_ID

* Mes_ID

* Trimestre_ID

* Semestre_ID

* Año_ID

+ Quincena

+ Temporada

TIEMPO

#* Tiempo_ID

* Dia_ID

* Mes_ID

* Trimestre_ID

* Semestre_ID

* Año_ID

+ Quincena

+ Temporada

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 todoDETALLE_CLIENTE

Cliente_ID

Dirección

Telefono

Total_compras

Edad

Sexo

Estado_civil

VENTAS

Ventas_ID

Cliente_ID

Tiempo_ID

Producto_ID

Tienda_ID

Numero_Orden

Fecha

Total_ventasPrecioCostoMargen

Bodega_ID

Agotado

Vendido

CLIENTE

Cliente_ID

Nombre

PRODUCTO

Producto_ID

Item_ID

Familia_ID

Clase_ID

Total_Productos

TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

* Total_tiendas

SECTOR

Sector_ID

Estrato_ID

Vigencia

HISTORIA_PROD

Producto_ID

Fecha_instantanea

Item_ID

Familia_ID

Clase_ID

Versión

TIEMPO

Tiempo_ID

Dia_ID

Mes_ID

Trimestre_ID

Semestre_ID

Año_ID

Quincena

Temporada

DETALLE_CLIENTE

Cliente_ID

Dirección

Telefono

Total_compras

Edad

Sexo

Estado_civil

DETALLE_CLIENTE

Cliente_ID

Dirección

Telefono

Total_compras

Edad

Sexo

Estado_civil

VENTAS

Ventas_ID

Cliente_ID

Tiempo_ID

Producto_ID

Tienda_ID

Numero_Orden

Fecha


Bodega_ID

Agotado

Vendido

VENTAS

Ventas_ID

Cliente_ID

Tiempo_ID

Producto_ID

Tienda_ID

Numero_Orden

Fecha


Bodega_ID

Agotado

Vendido

CLIENTE

Cliente_ID

Nombre

CLIENTE

Cliente_ID

Nombre

PRODUCTO

Producto_ID

Item_ID

Familia_ID

Clase_ID

Total_Productos

PRODUCTO

Producto_ID

Item_ID

Familia_ID

Clase_ID

Total_Productos

TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

* Total_tiendas

TIENDA

#* Tienda_ID

* Geometria_ID

* Ubicación

* Total_tiendas

SECTOR

Sector_ID

Estrato_ID

Vigencia

SECTOR

Sector_ID

Estrato_ID

Vigencia

HISTORIA_PROD

Producto_ID

Fecha_instantanea

Item_ID

Familia_ID

Clase_ID

Versión

HISTORIA_PROD

Producto_ID

Fecha_instantanea

Item_ID

Familia_ID

Clase_ID

Versión

TIEMPO

Tiempo_ID

Dia_ID

Mes_ID

Trimestre_ID

Semestre_ID

Año_ID

Quincena

Temporada

TIEMPO

Tiempo_ID

Dia_ID

Mes_ID

Trimestre_ID

Semestre_ID

Año_ID

Quincena

Temporada

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 :

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




Calidad de Datos



Acceso a los datos


Documentaciòn

Prueba

Entrenamiento

Transiciòn


Procesos del proyecto

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 planes

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 negocio 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:

ESTRATEGIA

DEFINICION

ANALISIS

DISEÑO

CONSTRUCCION

TRANSICION A

LA PRODUCCION

REVISION Y EVALUACION




Calidad de Datos



Acceso a los datos


Documentaciòn

Prueba

Entrenamiento

Transiciòn


ESTRATEGIA

DEFINICION

ANALISIS

DISEÑO

CONSTRUCCION

TRANSICION A

LA PRODUCCION

REVISION Y EVALUACION




Calidad de Datos



Acceso a los datos


Documentaciòn

Prueba

Entrenamiento

Transiciòn


Fases y Procesos del proyecto

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


Empresa

010101010101010101

010101010101010101

010101010101010101

010101010101010101

BD OLTP

Archivos Planos


ODS




OLAPData Marts

Datos de

Análsis

Data

Mining


Empresa

010101010101010101

010101010101010101

010101010101010101

010101010101010101

010101010101010101

010101010101010101

010101010101010101

010101010101010101

BD OLTP

Archivos Planos


ODSODS




OLAPData Marts

Datos de

Análsis

Data

Mining

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 METODOLOGÍCA DE UN SPATIAL … poblado de la misma a partir de los sistemas...

Documents

Transcript of APROXIMACIÓN METODOLOGÍCA DE UN SPATIAL … poblado de la misma a partir de los sistemas...