Data Warehouse Systems - Design and Implementation (PDFDrive) - Part4.en - Es

11.
8 Diseño de almacén de datos 1

espaciales
los usuarios pueden expresar qué datos espaciales necesitan para explotar
las características de los modelos multidimensionales y realizar varios
tipos de análisis espacial, y el proceso de diseño puede realizarse siguiendo
los mismos pasos que para el diseño de un almacén de datos tradicional.
Especificació
Identificar Determinar
n de
usuarios las
requisitos de
necesidades
documentos
de análisis
B Agrega
Inclusión tardía r
de apoyo soporte
espacial espaci
al
Definir
Verifique la Definir
esquema esquemas y
conceptual disponibilidad de asignacione
inicial datos y s
especifique conceptuale
asignaciones s finales
Figura 11.16 Pasos del enfoque basado en análisis para almacenes de datos espaciales.
(a) Fase de especificación de requisitos. (b) Fase de diseño conceptual
La fase de diseño conceptual (Fig. 11.16b) comienza con el desarrollo del

esquema inicial de almacenamiento de datos espaciales. Tenga en cuenta
que este esquema ya incluye elementos espaciales, ya que suponemos que
los usuarios pueden hacer referencia a datos espaciales cuando expresan
sus necesidades específicas de análisis. Por lo tanto, seguimos el camino
inferior de la Fig.11.16B. En el siguiente paso, debemos determinar si los
datos están disponibles en los sistemas fuente. Luego, se deben especificar
las asignaciones correspondientes con los elementos del almacén de datos.
Sin embargo, tenga en cuenta que pueden ser necesarias fuentes externas
si el soporte espacial requerido no existe en los sistemas fuente. En el
último paso, se desarrolla el esquema final; incluye todos los elementos del
almacén de datos para los que existen los datos correspondientes en los
sistemas de origen (ya sean internos o externos). Además, se entrega el
mapeo final entre los dos tipos de sistemas.
Inclusión tardía de apoyo espacial
Puede suceder que los usuarios no estén familiarizados con la gestión de

datos espaciales o que prefieran comenzar expresando sus necesidades de
análisis relacionadas con elementos no espaciales e incluir apoyo espacial
más adelante. En este caso, las fases de especificación de requisitos y
2 11 almacenes de datos
diseño conceptual proceden como en un almacén de datos tradicional,
ignorando las características espaciales hasta que se verifica el esquema
inicial con respecto a los datos disponibles en los sistemas fuente. Como
11.8 Diseño de almacén de datos 3
espaciales
mostrado en la Fig. 11.16b, antes del desarrollo del esquema final y los
mapeos correspondientes, hay un paso adicional para agregar soporte
espacial. En este paso, los diseñadores presentan el esquema conceptual a
los usuarios y les piden indicaciones sobre el soporte espacial requerido.
Si el modelo MultiDim se utiliza como modelo conceptual para diseñar
un almacén de datos espaciales, en el primer paso los diseñadores pueden
considerar cada nivel y decidir si ese nivel, algunos de sus atributos o
ambos deben representarse espacialmente. Entonces, si una jerarquía
incluye dos niveles espaciales relacionados, se puede especificar una
restricción topológica entre ellos. Si un hecho relaciona dos o más
dimensiones espaciales, los diseñadores pueden ayudar a los usuarios a
determinar si existe una restricción topológica entre estas dimensiones.
Finalmente, se puede considerar la inclusión de medidas espaciales. Tenga
en cuenta que los elementos del esquema multidimensional podrían
analizarse en un orden diferente, dependiendo de las habilidades de los
diseñadores y su conocimiento sobre los almacenes de datos espaciales y
las particularidades del modelo conceptual utilizado. Similar al caso
anterior, El paso de verificar la disponibilidad de los datos puede requerir
acceso a fuentes externas, ya que los datos espaciales pueden no estar
presentes en los sistemas fuente subyacentes. El esquema final debe incluir
las asignaciones modificadas.
Como ejemplo, considere el esquema de la Fig. 4.2, desarrollado para un
data warehouse tradicional siguiendo el método descrito en el Cap. 10.
Cuando se mostró este esquema a los usuarios, estos requirieron la
posibilidad de visualizar en mapas las jerarquías geográficas para las
dimensiones de Cliente, Proveedor y Empleado. Figura11,4 muestra la
adición de propiedades geográficas a las jerarquías en el esquema
conceptual inicial. Usamos la extensión espacial del modelo MultiDim
descrito en la Secta.11,2. Luego, los elementos espaciales se verifican con
los datos disponibles en los sistemas de origen. Dado que los datos
operativos no incluyen componentes espaciales, se utilizaron fuentes
externas para obtener la información correspondiente para estas jerarquías
espaciales.
Enfoque basado en fuentes
Como se explica en el Cap. 10, este enfoque se basa en los datos de los
sistemas de origen. Al igual que en el enfoque basado en análisis, el apoyo
espacial puede incluirse al principio o al final del proceso de diseño. Dado
que las bases de datos operativas son la fuerza impulsora de este enfoque,
la elección entre la inclusión temprana o tardía de los requisitos espaciales
depende de si estas bases de datos son espaciales o no.
Inclusión temprana de apoyo espacial
Si los sistemas de origen incluyen datos espaciales, se pueden aplicar pasos

similares a los del diseño de almacén de datos tradicional. Están indicados
en la Fig.11.17ay el camino inferior de la Fig. 11.17B. La especificación de
requisitos comienza con
espaciales
a
Identificar Especificació
Aplicar proceso
sistemas n de
de
de origen requisitos de
derivación
documentos

B Agregar soporte espacial
Validar el esquema
Definir esquema conceptual inicial conceptual con los usuarios
Definir esquemas y asignaciones conceptual
Figura 11.17 Pasos del enfoque basado en fuentes para almacenes de datos espaciales.
(a)
Fase de especificación de requisitos. (b) Fase de diseño conceptual
la identificación de los sistemas de origen que pueden servir como

proveedores de datos para el almacén de datos espaciales. Las fuentes
externas no se consideran en esta etapa. En el segundo paso, estas fuentes
se analizan para descubrir elementos de esquema multidimensionales. En
la literatura no se ha propuesto ningún procedimiento semiautomático o
automático para derivar el esquema de un almacén de datos espaciales a
partir de los esquemas de los sistemas fuente. Por lo tanto, este proceso de
derivación debe realizarse manualmente y debe basarse en el conocimiento
de los diseñadores del dominio comercial y de los conceptos de
almacenamiento de datos espaciales. El esquema multidimensional
obtenido, así como los metadatos correspondientes, se documentan en el
tercer paso de la fase de especificación de requisitos.
En el primer paso de la fase de diseño conceptual, se desarrolla un
esquema conceptual con elementos espaciales. Este esquema se muestra a
los usuarios para determinar su interés e identificar elementos que son
importantes para el análisis. Las recomendaciones de los usuarios para los
cambios se reflejarán en el esquema final obtenido en el último paso,
donde también se desarrollan mapeos entre los esquemas de origen y
almacén de datos.
Este caso ocurre cuando los sistemas de origen no incluyen datos

espaciales o contienen datos espaciales, pero el proceso de derivación es
complejo y los diseñadores prefieren centrarse primero en elementos no
espaciales y abordar el soporte espacial más adelante. Por lo tanto, el
proceso de diseño avanza como para un almacén de datos tradicional con
la adición de un paso para agregar soporte espacial. Tenga en cuenta que
este soporte se considera solo para los elementos elegidos previamente del
esquema multidimensional. Esto se muestra en la figura.11.17ay el camino
superior de la Fig. 11.17B.
espaciales
Si se utiliza el modelo MultiDim para representar el esquema de
almacenamiento de datos tradicional, el análisis de qué elementos se
pueden representar espacialmente se puede realizar de una manera similar
a la del enfoque basado en análisis anterior. Si los sistemas operativos
subyacentes no brindan soporte espacial, las fuentes externas pueden
entregar los datos espaciales requeridos. El mapeo correspondiente debe
incluirse como parte del esquema final.
Nosotros No incluya un ejemplo para ilustrar este enfoque, ya que dicho
ejemplo procedería de la misma manera que para la creación de un
esquema utilizando el enfoque basado en fuentes en el caso de un almacén
de datos tradicional y para agregar soporte espacial en el análisis basado en
acercarse arriba.
Enfoque basado en análisis / fuente
a
Enfoque Especificació
Determinar
basado en Identificar n de
las
análisis usuarios requisitos de
necesidades
documentos
de análisis
Especificació
Enfoque Identificar Aplicar proceso
n de
basado en sistemas de
requisitos de
fuentes de origen derivación
documentos
B Inclusión tardía de apoyo espacial

Agregar soporte espacial
Definir esquema conceptual inicial

Enfoque
basado en
análisis Definir esquemas y asignaciones
Coincidir con los dos esquemas conceptuales
Definir esquema conceptual inicial

Enfoque
basado en
fuentes
Figura 11.18 Pasos del enfoque basado en análisis / fuente para almacenes de datos
espaciales.
(a) Fase de especificación de requisitos. (b) Fase de diseño conceptual
Este enfoque combina los dos enfoques descritos anteriormente que se

pueden usar en paralelo, como se menciona en la Sec. 10.3.5. Se pueden
distinguir dos cadenas de actividades, correspondientes a los enfoques
impulsados por análisis y basados en fuentes, como se puede ver en la
Fig.11.18. La figura muestra los pasos del enfoque basado en análisis /
fuente para almacenes de datos espaciales. De manera similar a los casos
anteriores, proponemos dos soluciones diferentes, cuya elección depende
de si los usuarios están familiarizados con los conceptos relacionados con
el espacio.
11.9 Resumen 467
datos y si los sistemas de origen incluyen datos espaciales. La discusión

sobre la inclusión temprana o tardía del soporte espacial en este enfoque es
análoga a las de las secciones anteriores, por lo que la omitimos.
11.8.2 Lógico y diseño físico

El diseño lógico y físico de un almacén de datos espaciales debe considerar
los diversos aspectos mencionados en las Secciones. 10,5 y 10,6 para los
almacenes de datos tradicionales, que se refieren al mapeo de un esquema
conceptual en un esquema lógico y físico y al proceso ETL, todos estos
también se discutieron ampliamente anteriormente en este libro. Para
evitar la redundancia, no repetimos aquí las explicaciones.
11.9 Resumen
En este capítulo, estudiamos cómo se pueden ampliar los almacenes de

datos con datos espaciales. Para ello, presentamos una extensión espacial
del modelo conceptual MultiDim con tipos espaciales y tipos de campo y
definimos un conjunto de operaciones que se pueden realizar sobre ellos.
Ampliamos las jerarquías estudiadas en los capítulos.4 y 5 para incluir
datos espaciales, produciendo jerarquías espaciales. También
generalizamos las reglas para traducir modelos conceptuales a lógicos para
dar cuenta de los datos espaciales. Luego, abordamos los modelos
vectoriales y ráster para explicar cómo se pueden representar los tipos de
datos abstractos espaciales en el nivel lógico. Como en el resto del libro,
usamos como ejemplo el almacén de datos de Northwind, que ampliamos
con datos espaciales. Llamamos a esta extensión el almacén de datos de
GeoNorthwind. Implementamos los conceptos anteriores utilizando
PostGIS, la extensión espacial de la base de datos PostgreSQL, y
GeoMondrian, la extensión espacial del servidor OLAP de Mondrian.
También mostramos cómo se puede consultar el almacén de datos
GeoNorthwind usando una extensión espacial de MDX y con SQL
extendido con funciones espaciales. Finalmente describimos un método
para el diseño de almacenes de datos espaciales, que amplía el método para
el diseño de almacén de datos tradicional presentado en el capítulo
anterior. Como en el caso tradicional, presentamos tres enfoques
diferentes, dependiendo de si la fuerza impulsora son las necesidades de
análisis, la información en los sistemas fuente o ambos. Para cada uno de
estos tres enfoques, consideramos dos situaciones, dependiendo de cuándo
se incluyen los datos espaciales en el proceso.
11.10 Notas bibliográficas
Hay muchos libros sobre bases de datos espaciales y sistemas de

información geográfica (SIG). Los libros populares sobre estos temas son
[174, 187, 229, 234]. SQL / MM, la extensión espacial de SQL, es un
estándar ISO [94], que también se describe en [132, 134]. La norma ISO
19123: 2005 [93] define un esquema conceptual para las coberturas, que
son implementaciones lógicas de campos continuos como rásteres y TIN.
Un libro que presenta las características principales de PostGIS es [146]. El
libro [143] describe GRASS, un SIG de código abierto que incluye
capacidades avanzadas para manipular datos ráster.
La extensión espacial del modelo MultiDim presentado en este capítulo
se basa en los tipos de datos espaciales de MADS [155], un modelo
conceptual espacio-temporal, y sobre el trabajo sobre tipos de campo de los
presentes autores [69, 212, 214]. La noción de SOLAP se introdujo en
[176], y se revisa en [11]. Otros trabajos relevantes sobre SOLAP se pueden
encontrar en [13, 14, 224]. Un libro que presenta a Mondrian es [10].
Aunque no se ha trabajado mucho sobre el tema del análisis OLAP de
campos continuos (ver [5, 6]), este tipo de datos se ha estado estudiando
durante muchos años en SIG. Un álgebra para campos se de fi nió en el
libro clásico de Tomlin [202] y continuado por el trabajo de varios autores
[24, 34, 138, 154].
Dado que el almacenamiento de datos espaciales es un área de
investigación relativamente reciente, los aspectos metodológicos de su
diseño no se han abordado mucho en la literatura (ver, por ejemplo, [63,
64, 125]).
11.11 Preguntas de revisión
11.1 ¿Qué son las bases de datos espaciales? Describir dos formas
complementarias de modelar datos espaciales en aplicaciones de
bases de datos.
11.2 Describir los distintos tipos de datos espaciales a nivel conceptual,
dando para cada uno de ellos un ejemplo de su uso.
11.3 Defina las diversas relaciones topológicas en términos del límite,
interior y exterior de los valores espaciales.
11.4 ¿Qué son los campos continuos? ¿Cómo se implementan a nivel
conceptual?
11.5 Dé ejemplos de operaciones asociadas con tipos de campo. Explique
las operaciones de tasa de cambio para tipos de campo.
11.6 Explique por qué se deben eliminar las operaciones tradicionales
para los tipos de campo. Ilustre esto con ejemplos.
11.7 Discuta los siguientes conceptos: dimensión espacial, nivel espacial,
atributo espacial, hecho espacial, medida espacial, jerarquía
espacial y relación topológica.
11.12 4
11.8 ¿Cuáles son las diferencias entre un nivel espacial, un nivel espacial
con atributos espaciales y un nivel no espacial con atributos
espaciales?
11.9 Dé un ejemplo de cada una de las siguientes jerarquías espaciales:
jerarquías equilibradas, desequilibradas y generalizadas.
11.10 ¿Cuál es la diferencia entre jerarquías espaciales alternativas y
paralelas?
11.11 ¿Por qué se necesitan relaciones topológicas n-arias en hechos
espaciales? Están
tales relaciones habituales en las bases de datos espaciales?
11.12 ¿En qué se diferencia una medida espacial de una medida numérica
calculada con operaciones espaciales? ¿Una medida espacial
requiere estar relacionada con dimensiones espaciales?
11.13 Dé un ejemplo de un esquema multidimensional que contenga una
medida espacial. Transforma la medida espacial en una dimensión
espacial. Compare los dos esquemas con respecto a las diversas
consultas que se les pueden dirigir.
11.14 Defina el geoide y el elipsoide. ¿Para qué se usan? ¿Cuáles son las
diferencias entre ellos? ¿Qué es un dato?
11.15 ¿Qué son los SRS?
11.16 ¿Cuál es la diferencia entre el vector y los modelos de datos ráster
para representar datos espaciales?
11.17 Describe los tipos de datos espaciales implementados en SQL / MM.
11.18 Describa cómo se implementan los tipos de campo en PostGIS. ¿En
qué se diferencia esta implementación de la definición abstracta de
tipos de campo?
11.19 Analice las reglas de mapeo para traducir un esquema MultiDim
espacial en un esquema relacional. Indique las ventajas y
desventajas de las asignaciones alternativas.
11.20 ¿Cómo se representa una relación topológica entre niveles
espaciales en un esquema lógico?
11.21 ¿Cómo se puede comprobar en un esquema lógico la relación
topológica de un hecho?
11.22 Describir desde una perspectiva metodológica cómo se pueden
incluir los datos espaciales en los almacenes de datos.
11.12 Ejercicios
11.1 Considere el cubo GeoFoodmart, cuyo esquema se muestra en la Fig.

11.19. Escribe en MDX las siguientes consultas:
(a) Para cada tienda, proporcione las ventas totales a los clientes de
la misma ciudad que la tienda.
(b) Para cada tienda, obtenga la relación entre las ventas a clientes
del mismo estado y sus ventas totales en 2013.
Familia
Geografí
Apellido
País Cliente
Nombre del país País Geom
Departamento Identificación del cliente Primer nombre Inic
Nombre de Nb Vivienda para niños Dueño de la casa
Expresar Geom de cliente de propiedad de Nb Cars
Departamento
Nombre del Estado Estado Geom
CategoríaCiudad
nombre de laNombre de la ciudad Ciudad Geom
categoría
Subcategoría
Nombre de la
subcategoría
Geografía Tienda
Producto de clase ID de tienda Nombre de la tienda Tipo deAño
tienda
ID del Producto Nombre del producto SKUde tienda Tienda Pies cuadrados Supermercados Pies cuadrados C
Gerente
SRP Año No
Marca
Trimestre
Marca Marca
Nombre del
trimestre
Mes
Mes No
Nombre del
mes
Promoción
Nombre de la promoción Ventas

Calendario
Ventas en tienda Ventas por unidad de costo en tienda
Medios de comunicación /Promedio de ventas Hora
/Lucro
Fecha
Medios de Nombre del día Semana Día Nb Mes Sema
promoción
Tipo de medio
Figura 11.19 Esquema conceptual del cubo GeoFoodmart
(c) Muestre las ventas unitarias por marca de producto,

considerando solo las ventas a clientes de un país diferente al
país de la tienda.
(d) Muestre todas las medidas resumidas para las tiendas ubicadas
en California o Washington, considerando solo las tiendas en
California que están a menos de 200 km de Los Ángeles y las
tiendas en Washington que están a menos de 200 km de Seattle.
(e) Total ventas de tiendas ubicadas a menos de 5 km del centro de la
ciudad contra las ventas totales de todas las tiendas de su estado.
(f) Para cada tienda, enumere las ventas totales a los clientes que
viven a menos de 10 km de la tienda frente a las ventas totales de
la tienda.
11.12 4
(g) Para cada ciudad, indique la tienda más cercana al centro de la
ciudad y su marca más vendida.
(h) Dar la unión espacial de todas las ciudades que tienen más de
una tienda con una superficie de más de 10,000 pies cuadrados.
(i) Dar la unión espacial de los estados tal que el promedio de las
ventas totales por cliente en 1997 sea mayor a $ 60 por mes.
(j) Dar la unión espacial de todas las ciudades donde todos los
clientes han comprado por más de $ 100.
(k) Muestre la unión espacial de las ciudades cuyas ventas
contabilizan más del 5% de todas las ventas.
11.2 Considere el almacén de datos de GeoFoodmart, cuyo esquema
relacional se muestra en la Fig. 11.20. Escribe en SQL las consultas
planteadas en el ejercicio anterior.
11.3 Agregue datos espaciales al esquema de almacenamiento de datos
que creó como una solución de Ej. 5.9 para la aplicación AirCarrier.
Debe analizar las dimensiones, hechos y medidas y definir cuál de
ellos puede ampliarse con características espaciales. También debe
considerar agregar datos de campo continuos que representen la
altitud para que pueda mejorar el análisis tratando de encontrar una
correlación entre los resultados y la elevación de los sitios
geográficos.
11.4 Considere el esquema lógico obtenido como solución de Ej. 11,3.
Utilizando la técnica de ingeniería inversa que prefiera, genere un
esquema multidimensional a partir de ella.
11.5 Escribir en MDX las siguientes consultas sobre el esquema del cubo
obtenido en Ej. 11,4:
(a) Para cada aerolínea y año, indique el número de vuelos
programados y realizados.
(b) Para cada aeropuerto, indique el número de vuelos programados
y realizados en los últimos 2 años.
(c) Para cada aerolínea y grupo de distancia, indique el número total
de asientos vendidos en 2012 por aerolínea.
(d) Indique el número total de personas que llegaron o salieron de
aeropuertos a menos de 15 km del centro de la ciudad en 2012.
(e) Indique por año la relación entre vuelos en aeropuertos a menos
de 15 km del centro de la ciudad y vuelos en aeropuertos ubicados
entre 15 y 40 km del centro de la ciudad.
(f) Visualice la unión espacial de todos los aeropuertos con más de
5.000 salidas en 2012.
(g) Visualice la unión espacial de todos los aeropuertos donde operan
más de 100 transportistas.
(h) Para ciudades operadas por más de un aeropuerto, indique el
número total de pasajeros que llegan y salen.
país Tienda
cliente
country_id country_name country_geom
store_id store_type region_id nombre_tien
Identificación del cliente
store_street_address store_city store_stat
núm_cuenta
store_sqft grocery_sqft frozen_sqft meat_s
lname
fname
mi Expresa
Dirección 1 r
dirección 2
dirección3 state_id
dirección4 state_name
ciudad state_geom
Provincia del estado country_id
código postal
país
customer_region_id ciudad
teléfono1
phone2 city_id
fecha de nacimiento city_name
estado civil city_geom
Ingresos anuales state_id
género
total_children promoción
num_children_at_home
educación id_promoción promoción_distrito_id nombre_promoción media_type
costo fecha_inicio fecha_finalización
date_accnt_opened
tarjeta_miembro
ocupación
dueño de casa
num_cars_owned
customer_geom
city_id producto
sales_fact
ID del Producto product_class_id brand_n
time_by_day SRP store_id store_sales store_cost un
product_id time_id customer_id Promotion_id
peso_bruto peso_neto_paquete_reciclable
time_id the_date the_day the_month the_year day_of_month week_of_year month_of_year trimestre fisca
clase_producto
product_class_id product_subcategory categoría_producto departamento
Figura 11.20 Esquema relacional del almacén de datos de GeoFoodmart

11.12 4
(i) Para ciudades operadas por más de un aeropuerto, indique el
número total de pasajeros que llegan y salen en el aeropuerto más
cercano al centro de la ciudad y la relación entre este valor y el
total de la ciudad.
(j) Visualice la unión espacial de todos los aeropuertos ubicados a
más de 1000 m sobre el nivel del mar.
(k) Compare el número de vuelos programados y salidos para los
aeropuertos ubicados por encima y por debajo de los 1000 m
sobre el nivel del mar en 2012.
11.6 Escribir en SQL las consultas de Ex. 11,5 encima el esquema lógico
obtenido en Ex. 11,3.
Capítulo 12
Almacenes de datos de trayectoria
El capítulo anterior se centró en el análisis de las características espaciales

de objetos estáticos como tiendas, ciudades o estados, donde por estático
entendemos que las características espaciales de estos objetos no cambian
(o cambian excepcionalmente) a lo largo del tiempo. Sin embargo, existe
un amplio abanico de aplicaciones que requieren el análisis de los
denominados objetos en movimiento, es decir, objetos que cambian
continuamente de posición en el espacio y el tiempo. A esto se le llama
análisis de datos de movilidad. El interés en el análisis de datos de
movilidad se ha expandido drásticamente con la disponibilidad de
dispositivos de posicionamiento integrados como GPS. Con estos
dispositivos, los datos de tráfico, por ejemplo, pueden capturarse como una
colección de secuencias de señales de posicionamiento transmitidas por el
GPS de los automóviles a lo largo de sus itinerarios. Dado que estas
secuencias pueden ser muy largas, a menudo se procesan dividiéndolas en
segmentos. Por ejemplo, el movimiento de un automóvil se puede
segmentar con respecto a la duración de los intervalos de tiempo en los que
se detiene en un lugar determinado. Estos segmentos de movimiento se
denominan trayectorias y son la unidad de interés en el análisis de datos de
movimiento. El análisis de trayectoria se puede aplicar, por ejemplo, en la
gestión del tráfico, que requiere monitorear y analizar los flujos de tráfico
para capturar sus características. Otras aplicaciones tienen como objetivo
rastrear la posición de los usuarios de redes sociales registrada por los
dispositivos electrónicos que llevan, como teléfonos inteligentes o tabletas,
con el fin de analizar su comportamiento. Como hemos visto a lo largo de
este libro, los almacenes de datos y las técnicas OLAP se han utilizado con
éxito para transformar datos detallados en conocimientos valiosos para la
toma de decisiones.
Nosotros comienza este capítulo en la Secta. 12,1 motivar el análisis de
datos de movilidad. Luego,
en la Secta. 12,2, definimos tipos temporales, que proporcionan una forma
de representar a nivel conceptual valores que evolucionan en el tiempo,
mientras que en Sect. 12,3 nosotros dar una posible implementación para
estos tipos en PostGIS. En la secc.12,4, presentamos el almacén de datos de
trayectoria de Northwind. Finalmente, la Secta.12,5 se dedica a consultar
almacenes de datos de trayectoria.
11.12 4
A. Vaisman y E. Zimańyi, sistemas de almacenamiento de datos, 475

sistemas y aplicaciones centrados en datos, DOI 10.1007 / 978-3-642-
54655-6 12,
© Springer-Verlag Berlín Heidelberg 2014
4 12 almacenes de datos de
12.1 Análisis de datos de movilidad
Hoy en día, con la masificación de dispositivos de posicionamiento como el

GPS, podemos recopilar grandes cantidades de datos de movilidad, que
pueden ser extremadamente valiosos en muchas áreas de aplicación. Un
escenario de aplicación típico es el análisis de las actividades que realizan
los turistas en una ciudad. Durante su estadía, los turistas visitan museos,
parques y varias atracciones diferentes. También consumen muchos
servicios como alojamiento, restaurantes, tiendas, etc. Desde el punto de
vista de un analista, estos lugares y servicios turísticos se denominan
lugares de interés. Una trayectoria turística consiste en desplazarse de un
lugar de interés a otro, deteniéndose durante algún tiempo en alguno de
ellos. Los datos sobre estas trayectorias se pueden recoger y analizar, por
ejemplo, para optimizar la oferta de servicios o planificar itinerarios
turísticos dentro de la ciudad. Como otro ejemplo, las grandes ciudades
industriales con altas tasas de propiedad de automóviles están sufriendo
una disminución en la calidad del aire. Normalmente, las estaciones están
ubicadas en diferentes puntos en estas ciudades para medir la calidad del
aire a intervalos de tiempo regulares. No es difícil adivinar que las técnicas
que hemos estudiado en este libro pueden ser de gran utilidad para
comprender y analizar la evolución de la calidad del aire y los efectos de las
medidas correctivas que los gobiernos puedan tomar para mantener la
contaminación por debajo de ciertos límites. Por ejemplo, podemos
analizar las trayectorias que siguen los automóviles, camiones y autobuses
y correlacionarlas con las medidas de calidad del aire. O podemos estudiar
la población que está expuesta a fuertes cargas contaminantes y cuándo
ocurre. Las estaciones están ubicadas en diferentes puntos de estas
ciudades para medir la calidad del aire a intervalos de tiempo regulares. No
es difícil adivinar que las técnicas que hemos estudiado en este libro
pueden ser de gran utilidad para comprender y analizar la evolución de la
calidad del aire y los efectos de las medidas correctivas que puedan tomar
los gobiernos para mantener la contaminación por debajo de ciertos
límites. Por ejemplo, podemos analizar las trayectorias seguidas por
automóviles, camiones y autobuses y correlacionarlas con las medidas de
calidad del aire. O podemos estudiar la población que está expuesta a
fuertes cargas contaminantes y cuándo ocurre. Las estaciones están
ubicadas en diferentes puntos de estas ciudades para medir la calidad del
aire a intervalos de tiempo regulares. No es difícil adivinar que las técnicas
que hemos estudiado en este libro pueden ser de gran utilidad para
comprender y analizar la evolución de la calidad del aire y los efectos de las
medidas correctivas que los gobiernos puedan tomar para mantener la
contaminación por debajo de ciertos límites. Por ejemplo, podemos
analizar las trayectorias seguidas por automóviles, camiones y autobuses y
correlacionarlas con las medidas de calidad del aire. O podemos estudiar la
población que está expuesta a fuertes cargas contaminantes y cuándo
ocurre. No es difícil adivinar que las técnicas que hemos estudiado en este
libro pueden ser de gran utilidad para comprender y analizar la evolución
de la calidad del aire y los efectos de las medidas correctivas que los
gobiernos puedan tomar para mantener la contaminación por debajo de
12.2 Tipos 4
ciertos límites. Por ejemplo, podemos analizar las trayectorias seguidas por
automóviles, camiones y autobuses y correlacionarlas con las medidas de
calidad del aire. O podemos estudiar la población que está expuesta a
fuertes cargas contaminantes y cuándo ocurre. No es difícil adivinar que las
técnicas que hemos estudiado en este libro pueden ser de gran utilidad
para comprender y analizar la evolución de la calidad del aire y los efectos
de las medidas correctivas que puedan tomar los gobiernos para mantener
la contaminación por debajo de ciertos límites. Por ejemplo, podemos
analizar las trayectorias que siguen los automóviles, camiones y autobuses
y correlacionarlas con las medidas de calidad del aire. O podemos estudiar
la población que está expuesta a fuertes cargas contaminantes y cuándo
ocurre.
En el Cap. 11, hemos estudiado cómo las características espaciales de los
objetos pueden
estar representado en bases de datos y almacenes de datos. Aunque estas
características espaciales pueden cambiar con el tiempo, estos cambios
generalmente se consideran discretos. Por ejemplo, una parcela se puede
fusionar con otra en un instante determinado. Del mismo modo, las
fronteras de un estado o un país pueden cambiar con el tiempo. En este
capítulo, nos interesan los objetos cuyas características espaciales cambian
continuamente en el tiempo. Estos se denominan objetos en movimiento.
Si bien trataremos con puntos en movimiento en este capítulo, muchas
aplicaciones también deben tratar con regiones en movimiento, por
ejemplo, para monitorear la trayectoria de nubes contaminantes o
manchas en cuerpos marinos, como en nuestro ejemplo anterior. Las
trayectorias se pueden representar de forma continua o discreta. Una
trayectoria continua se compone de la trayectoria de movimiento de un
objeto, que ocurre dentro de un cierto intervalo, enriquecido con funciones
de interpolación que nos permiten calcular, con un grado razonable de con
fi anza, la posición espacio-temporal del objeto en movimiento para
cualquier instante de este intervalo. Por otro lado, una trayectoria discreta
se compone de la secuencia finita de posiciones espacio-temporales en un
cierto intervalo. La principal diferencia entre una trayectoria discreta y una
continua es que en la primera no existe una función de interpolación
plausible entre dos puntos. Como ejemplo típico, considere el caso de un
sitio web La principal diferencia entre una trayectoria discreta y una
sitio web La principal diferencia entre una trayectoria discreta y una
sitio web
de una red social como el sitio web de Foursquare. 1 Un usuario se registra

en un lugar a las 2 pm Al día siguiente, hace lo mismo a la 1 pm ya las 4 pm
se registra en otro lugar. La interpolación entre estos tres puntos espacio-
temporales probablemente será inútil para cualquier aplicación que quiera
analizar el movimiento de este usuario. Sin embargo, una aplicación
destinada a analizar la presencia de personas en un área determinada
puede encontrar útil esta información. Tenga en cuenta que la diferencia
entre trayectorias discretas y continuas tiene que ver con la semántica de la
aplicación más que con el tiempo entre dos puntos de trayectoria
consecutivos. Por ejemplo, si queremos realizar un análisis a largo plazo de
las posiciones de las personas, entonces puede darse el caso de que los
check-ins aleatorios en Foursquare puedan considerarse una trayectoria
continua.
Bases de datos espacio-temporales o las bases de datos de objetos
en movimiento almacenan y consultan las posiciones de los objetos en
movimiento. Por ejemplo, una consulta típica a una base de datos de
objetos en movimiento sería "¿Cuándo llegará el próximo tren desde
Roma?", Que es una consulta sobre un punto en movimiento. También
podemos consultar las regiones en movimiento y hacer preguntas como
"¿A qué velocidad se está reduciendo la selva tropical del Amazonas?". Sin
embargo, estas bases de datos no admiten consultas analíticas como
"Número total de entregas iniciadas en Bruselas en el último trimestre de
2012" o "Duración media de las entregas por ciudad". Estas consultas
pueden manejarse de manera más eficiente si los datos de movilidad se
almacenan en un almacén de datos. Los almacenes de datos
convencionales se pueden ampliar para admitir datos de objetos en
movimiento, lo que lleva al concepto de almacenes de datos
espaciotemporales o de trayectoria que, además de los datos alfanuméricos
y espaciales, contienen datos sobre las trayectorias de los objetos en
movimiento. Las trayectorias se analizan típicamente junto con otros
datos, por ejemplo, datos espaciales como la configuración de una red de
carreteras o datos de campo continuo como temperatura, precipitación o
elevación.
Como en el Cap. 11, para respaldar los datos espacio-temporales,
utilizamos un
recopilación de tipos de datos que capturan la evolución en el tiempo de los
tipos base y los tipos espaciales. Denotamos estos tipos como temporales y
los estudiamos en detalle en la siguiente sección.
12.2 Temporal Tipos
Los tipos temporales representan valores que cambian con el tiempo, por
ejemplo, para realizar un seguimiento de la evolución de los salarios de los
empleados. Conceptualmente, los tipos temporales son funciones que
asignan a cada instante un valor de un dominio particular. Se obtienen
aplicando un constructor temporal (). Por tanto, un valor ·de tipo temporal
(real) (por ejemplo, que representa la evolución del salario de un
empleado) es una función continua f: instantánea → real.
12.2 Tipos 4
http://www.foursquare.com
1
En lo que sigue, se supone que la dimensión de tiempo representa un

tiempo válido. En el campo de las bases de datos temporales, el tiempo
válido es el momento en que los valores de una determinada tupla son
válidos en la base de datos, mientras que el tiempo de transacción es el
momento en que se registra una tupla en la base de datos. Por ejemplo, si
el salario de un empleado se registra en la base de datos el 28 de diciembre
de 2013, este se almacenará como su tiempo de transacción, pero si se
mantiene para el empleado a partir del 1 de enero de 2014, esta última
fecha se registrará como el tiempo válido para este atributo.
Salari 20 30
o
John
Salario 60
María
2012-01- 2012-04-01 2012-07-01 2012-10-01 2013-01-01 2013-04-01

01
Figura 12.1 Ejemplos de reales temporales que representan la evolución de los salarios
Los tipos temporales son funciones parciales, es decir, pueden estar

indefinidos durante ciertos períodos de tiempo. Como ejemplo, SalaryJohn
y SalaryMary son valores de tipo temporal (real), que representan la
evolución del salario de dos empleados como se muestra en la Fig.12,1. Por
ejemplo, John tiene un salario de 20 en el período [2012-01-01, 2012-07-
01) y un salario de 30 en el período [2012-10-01, 2013-01-01), mientras
que el salario permanece indefinido entre 2012-07-01 y 2012-09-30.
Denotamos por '' este valor ⊥indefinido. Como convención, usamos
intervalos cerrados-abiertos.
Cuadro 12.1 Clases de operaciones sobre tipos temporales

Clase Operaciones
Proyección al dominio / rango DefTime, RangeValues, Trayectoria IsDe fi
Interacción con dominio / rango nedAt, HasValue, AtInstant, AtPeriod,
InitialInstant, InitialValue, FinalInstant,
FinalValue, At, AtMin, AtMax
Tasa de cambio Derivada, Velocidad, Giro
Agregación temporal Integral, Duración, Longitud,
TAvg, TVariance, TStDev, TMin,
Levantamiento TMax Todas las nuevas
operaciones inferidas
Los tipos temporales tienen un conjunto asociado de operaciones, que se

pueden agrupar en varias clases, como se muestra en la Tabla 12,1.
Discutimos a continuación estas operaciones. Primero, hay operaciones
que realizan la proyección en el dominio
y rango de la función que define el tipo temporal. Operaciones DefTime
y RangeValues devuelven, respectivamente, la proyección de un tipo
temporal
12.2 Tipos 4
en su dominio y rango. Por ejemplo, DefTime (SalaryJohn) y RangeVal- ues
(SalaryJohn) devuelven, respectivamente, {[2012-01-01, 2012-07-01),
[2012-10-01,
2013-01-01) y 20,30. Explicaremos la operación Trayectoria cuando

analicemos los} {tipos espaciales
} temporales a continuación.
Otro conjunto de operaciones permite la interacción con el dominio y el
rango. El predicado IsDe fi nedAt se utiliza para comprobar si la función
temporal se define en un instante o si alguna vez se define durante un
conjunto dado de
intervalos. De forma análoga, el predicado HasValue comprueba si la
función alguna vez asumió uno de los valores dados como segundo
argumento. Las operaciones AtInstant y AtPeriod restringen la función a
un tiempo determinado o un conjunto de intervalos de tiempo. Las
operaciones InitialInstant y InitialValue devuelven, respectivamente, el
primer instante en el que se define la función y el valor correspondiente.
Las operaciones FinalInstant y FinalValue son análogas. Operation At
restringe el tipo temporal a un valor o a un rango de valores en el rango de
la función. Las operaciones AtMin y AtMax reducen la función a los
instantes en que su valor es mínimo o máximo, respectivamente.
Para Por ejemplo, IsDe fi nedAt (SalaryJohn, 2012-06-15) y HasValue
(SalaryJohn, 25) dan como resultado, respectivamente, los valores
booleanos verdadero y falso. Además, AtInstant (SalaryJohn, 2012-03-15)
y AtInstant (SalaryJohn, 2012-07-15) devuelven, respectivamente, el valor
20 y '', porque el salario de John no está definido⊥en la última fecha. De
manera similar, AtPeriod (SalaryJohn, [2012-04-01, 2012-11-01)) da como
resultado un real temporal con valor 20 en [2012-04-01, 2012-
07-01) y 30 a [2012-10-01, 2012-11-01), donde los periodos han sido
proyectados a los intervalos dados como parámetro de la operación.
Además, InitialInstant (SalaryJohn) y InitialValue (SalaryJohn) devuelven
2012-01-01 y 20 que son, respectivamente, la hora inicial y el valor del
valor temporal. Además, At (SalaryJohn, 20) y At (SalaryJohn, 25)
devuelven, respectivamente, un real temporal con valor 20 en [2012-01-01,
2012-07-01) y '', porque no hay salario con valor 25 en⊥absoluto.
Finalmente, AtMin (SalaryJohn) y AtMax (SalaryJohn) devuelven,
respectivamente, un real temporal con valor 20 en [2012-01-01, 2012-07-
01) y un real temporal con valor 30 en [2012-10-01,
2013-01-01).
Una propiedad importante de cualquier valor temporal es su tasa de
cambio, calculada por la operación Derivative, que toma como argumento
un entero temporal o real y da como resultado un real temporal dado por la
siguiente expresión:
′ F (t + δ) - F (t)
F (t) = lim
δ→0 δ .
Para ejemplo, Derivative (SalaryJohn) da como resultado un real temporal

con valor 0 en [2012-01-01, 2012-07-01) y [2012-10-01, 2013-01-01). Las
otras operaciones
de esta clase se describirá en el contexto de los tipos espaciales temporales
más adelante en el capítulo.
Existen tres operaciones básicas de agregación temporal que toman
como argumento un entero temporal o real y devuelven un valor real.
Integral devuelve el área bajo la curva definida por la función, Duración
devuelve el
12.2 Tipos 4
duración de la extensión temporal en la que se define la función, y
Longitud devuelve la longitud de la curva definida por la función. Estas
operaciones se definen de la siguiente manera:
∫
• Integral:
• Duración
DX . ∫T Fdx(X)
.
: ∫T.
. Σ 2
d
1 d
• Largo T
A partir de estas operaciones, se pueden definir otras operaciones

derivadas. Estos están prefijados con una 'T' (temporal) para distinguirlos
de las operaciones de agregación usuales generalizadas a tipos temporales,
que discutimos a continuación.
• TAvg: Integral / Duración.
• TVarianza: (F (X)-TAvg)2
dx .
∫ √ T
• TStDe
Para Por ejemplo, la operación TAvg calcula la media ponderada de un
valor temporal, teniendo en cuenta la duración en la que la función toma
un valor. En nuestro ejemplo, TAvg (SalaryJohn) arrojará 23.25, dado que
John tuvo un salario de 20 durante 182 días y un salario de 30 durante 92
días. Además, TVariance y TStDev calculan la varianza y la desviación
estándar de un tipo temporal. Finalmente, TMin y TMax devuelven,
respectivamente, el valor mínimo y máximo tomado por la función. Estos
se obtienen por Min (RangeValues ()) y Max (RangeValues ()) donde Min y
Max son las operaciones
· clásicas sobre valores numéricos.
La generalización de las operaciones sobre tipos no temporales a tipos
temporales se denomina lifting. La elevación de una operación sobre tipos
no temporales reemplaza cualquiera de sus tipos de argumento por el tipo
temporal respectivo y devuelve un tipo temporal. Como ejemplo, la
operación menor que (<) ha levantado versiones donde uno o ambos de sus
argumentos pueden ser tipos temporales y el resultado es un booleano
temporal. Intuitivamente, la semántica de tales operaciones elevadas es
que el resultado se calcula en cada instante utilizando la operación no
elevada.
Se pueden aplicar varias definiciones de una operación cuando se
combinan dos tipos temporales definidos en diferentes extensiones
temporales. Una primera solución podría ser que el resultado se de fi ne en
la intersección de ambas extensiones e indefinidas.
en otra parte. Otra solución podría ser que el resultado se de fi ne en la
unión
de las dos extensiones, y un valor predeterminado (como 0, para la suma) se
utiliza para
las extensiones que pertenecen a un solo tipo temporal. Para las
operaciones elevadas, suponemos que el resultado se define en la
intersección de ambas extensiones.
De manera análoga, las operaciones de agregación también se pueden
levantar. Por ejemplo, una operación Avg elevada combina un conjunto de
reales temporales y da como resultado un nuevo real temporal en el que se
4
calcula 12 almacenes
el promedio en cada instante. Como ejemplo, dadosdelos
datos
dosdevalores
temporales anteriores, Avg (SalaryJohn, SalaryMary) da como resultado un
real temporal cuya representación gráfica se da en la Fig. 12,2.
12.2 Tipos 4
Salari 2030
o
John
60
Salari
o
María 2040604560
Prom
edio
2012-01- 2012-04-01 2012-07-01 2012-10-01 2013-01-01 2013-04-01

01
Figura 12.2 Representación gráfica del promedio temporal
12.2.1 Tipos espaciales temporales

Todas las operaciones para tipos temporales discutidas hasta ahora
también son válidas para tipos espaciales. Por ejemplo, un valor de tipo
temporal (punto), que puede representar la trayectoria de un camión, es
una función continua f: punto instantáneo. →
Nosotros presentará ahora algunas de las operaciones específicas de
Table 12,1 para el caso espacial. Usaremos como ejemplo dos puntos
temporales RouteT1 y RouteT2, que mantienen un registro de las rutas de
entrega seguidas por dos camiones T1 y T2 el mismo día, digamos, 10 de
enero de 2012. Se da una representación gráfica de las trayectorias de los
dos camiones. en la Fig.12,3. Podemos ver, por ejemplo, que el camión T1
tardó 10 minutos en ir del punto (0,0) al punto (2,2) y luego se detuvo
durante 15 minutos en ese punto. En este ejemplo, asumimos un
constantevelocidad entre pares de puntos. Por lo tanto, el camión T1 recorrió
una distancia
de 8 = 2,83 en 10 min, mientras que el camión T2 recorrió una distancia
de 5 = 2,23 pulgadas
los primeros 10 min y una distancia de 1 en los siguientes 5 min.
Y
8:25
8:10
2 8:20
T1
8:15
1
T2
8:00
123 X
8:05
Figura 12.3 Representación gráfica de las trayectorias de dos camiones
La operación Trayectoria proyecta geometrías temporales en el plano

(ver Tabla 12,1). La proyección de un punto temporal en el plano puede
consistir en puntos y líneas, mientras que la proyección de una línea
temporal en el plano puede
12.2 Tipos 4
constan de líneas y regiones. Finalmente, la proyección de una región
temporal en el plano consiste en una región. En nuestro ejemplo,
Trayectoria (RutaT1) dará como resultado la línea más a la izquierda en la
Fig.12,3, sin ninguna información temporal.
Todas las operaciones sobre tipos espaciales no temporales se eliminan
para permitir que cualquiera de los argumentos sea un tipo temporal y
devuelva un tipo temporal. Como ejemplo, la función Distancia, que
devuelve la distancia mínima cartesiana entre dos geometrías, tiene
versiones elevadas donde uno o ambos argumentos pueden ser puntos
temporales y el resultado es un real temporal. Intuitivamente, la semántica
de tales operaciones elevadas es que el resultado se calcula en cada instante
utilizando la operación no elevada. Eso significa que la función de distancia
elevada devuelve la distancia entre dos objetos espaciales en cualquier
momento dado. En nuestro ejemplo, Distancia (RutaT1, RutaT2) devuelve
un real temporal que se muestra en la Fig.12,4, donde, por ejemplo, la
función tiene un valor de 1,5 a las 8:10 y 1,41 a las 8:15.
8:05
8:10 8: 158: 20t
Figura 12.4 Distancia entre las trayectorias de los dos camiones en la Fig. 12,3
Las operaciones topológicas también se pueden levantar. En este caso, la

semántica es que la operación devuelve un booleano temporal que calcula
la relación topológica en cada instante. Por ejemplo, Intersects (RouteT1,
RouteT2) devolverá un booleano temporal con valor falso durante [8:05,
8:20] ya que los dos camiones nunca estuvieron en el mismo punto en
ningún instante de su ruta.
Una solicitud común es preguntar si dos puntos temporales satisfacen
una relación topográfica en un instante particular o en un período de
tiempo particular. Esto se puede obtener fácilmente aplicando primero las
operaciones AtInstant o AtPeriod y luego verificando la relación topológica
tradicional. Por ejemplo, podríamos preguntar si los dos camiones T1 y T2
se cruzan a las 8:30 con la expresión Intersects (AtInstant (RouteT1, 8:30),
AtInstant (RouteT2, 8:30)). Observe que aquí la operación Intersects
aplicada es la no levantada. En nuestro ejemplo, el resultado devuelve
falso. Sin embargo, tenga en cuenta que la razón podría ser la imprecisión
de las medidas en el tiempo y / o el espacio. Una solución a esto podría ser
definir un límite en el tiempo y el espacio. Esto se puede afirmar de la
siguiente manera:
Se cruza (Bu ff er (RouteT1, 0.6, 0:10), Bu er (RouteT2, 0.6, 0:10))
El término Buffer (RouteT1, 0.6, 0:10) de fi ne un cilindro elíptico, o

cilíndrico, alrededor de la trayectoria del camión, con un semieje de 0.6
sobre la dimensión espacial y un semieje de 10 min sobre la dimensión
temporal. . En este caso, los puntos iniciales de las trayectorias RouteT1 y
RouteT2 satisfarán la consulta, ya que se encuentran en la distancia 1; eso
significa dos círculos con radio
0.6 y con centros, respectivamente, en el punto (0,0) a las 8:00 y en el
punto (1,0) a las 8:05 tienen intersección no nula si la tolerancia de tiempo
es de 10 min. Lo mismo ocurre con los puntos finales de ambas
trayectorias.
Como hemos visto, las operaciones de agregación también se pueden
levantar. Por ejemplo, Union (RouteT1, RouteT2) dará como resultado una
única geometría temporal compuesta por las dos líneas de la Fig.12,3.
Nosotros de fi ne cuatro operaciones para calcular la tasa de cambio de
los puntos. Operation Speed produce el concepto habitual de velocidad de
un punto temporal en cualquier instante como un real temporal, definido
de la siguiente manera:
′ Fdistancia(F (t + δ), f (t)) .

F (t) = δ→0
lim δ
Operation Direction devuelve la dirección del movimiento, es decir, el
ángulo entre el eje xy la tangente a la trayectoria del punto en movimiento.
La Operación Giro produce el cambio de dirección en cualquier instante,
de fi nido de la siguiente manera:
Fdirecció n(F (t + δ), f (t)) .

F ′(t) = δ→0
lim δ
Finalmente, Derivative devuelve la derivada del movimiento como un real

temporal. Dimos la definición de Derivada en la sección anterior. Tenga en
cuenta que podemos obtener la aceleración de un punto temporal P por
Derivada (Velocidad (P)). Por ejemplo:
• La velocidad (RouteT1) produce un real temporal con valores de 16,9
en [8:00, 8:10] y 0 en [8:10, 8:25].
• Direction (RouteT1) produce un real temporal con valor de 45 a las
[8:00, 8:10].
• Turn (RouteT1) produce un real temporal con valor 0 a las [8:00, 8:10].
• La derivada (RouteT1) produce un real temporal con valor 1 en [8:00,
8:10]. Observe que durante la parada del camión, la dirección y el giro son
indefinidos.
12.2.2 Temporal Tipos de campo

Los campos temporales representan fenómenos que varían tanto en el
tiempo como en el espacio. Como se muestra en la Fig.12,5a, un campo
temporal puede conceptualizarse como una función que asigna un valor a
cada punto de un espacio espacio-temporal. Los campos temporales se
obtienen componiendo los constructores temporal y de campo. Por
12.2 Tipos 4
ejemplo,
aBC
t
v v
t v
t
t
y temporal (campo campo (temporal (·))
(·))
X
Figura 12.5 Tres posibles formas de conceptualizar los campos temporales
un valor de tipo temporal (campo (real)), que de fi ne una función f: instant

→
(puntual ), se puede utilizar para representar la temperatura, que varía
→
en el tiempo y el espacio. Observe que los tipos temporal (campo (real))
(Fig.12,5b) y de campo (temporal (real)) (Fig. 12,5c) son equivalentes, es
decir, asocian un valor real a un punto de un espacio espacio-temporal.
Todas las operaciones definidas para tipos temporales se aplican a
campos temporales, aunque algunas de ellas deben redefinirse, como
veremos a continuación. Suponga que la temperatura es un campo
temporal definido en Bélgica y que cubre el período [2010-01-01, 2012-12-
31]. DefTime (Temperature) produce el período anterior y RangeValues
(Temperature) arroja el rango de fi nido por la temperatura mínima y
máxima en todos los instantes del período anterior y todos los puntos
ubicados en Bélgica. De manera similar, AtInstant (Temperature, 2011-01-
01 08:00) produce un campo intemporal correspondiente a la temperatura
en ese instante en particular, mientras que AtPeriod (Temperature, [2012-
04-01, 2012-04-03]) devuelve un campo temporal proyectado sobre el
intervalo dado. Finalmente, InitialInstant (Temperature) y InitialValue
(Temperature) devuelven el primer instante para el que se define una
temperatura,
Tenemos visto que las operaciones AtMin y AtMax reducen la función
que define un valor temporal a los instantes en que su valor es mínimo o
máximo, respectivamente. Estas operaciones tienen como argumento un
valor temporal y devuelven un valor temporal. Como los campos
temporales varían tanto en el espacio como en el tiempo, se deben
considerar dos versiones de estas operaciones, dependiendo de si la
operación se aplica instante a instante o punto a punto. Por ejemplo,
AtMin t aplicado a un temporal (campo (real)) (ver Fig.12,5b) opera
instante a instante y aplica la operación AtMin al campo de reales válidos
en ese instante, restringiéndola así a los puntos del espacio donde su valor
es mínimo. Por otro lado, AtMin se aplica a un campo (temporal (real))
(ver Fig.12,5c) opera punto por punto y aplica la operación AtMin al real
temporal válido en ese punto, restringiéndola a los instantes donde su
valor es mínimo.
De manera similar, las operaciones de agregación elevadas deben
cambiarse de nombre para diferenciar aquellas que operan en el espacio o
en el tiempo. Por ejemplo, Sum sy Sum t corresponden a la operación Sum
levantada en el espacio y en el tiempo, respectivamente.
12.3 Implementación de tipos temporales en 4
Así, dado un conjunto de campos temporales ti que representan el número
de camiones de tipo i que están presentes en una ubicación en el espacio en
un instante particular, Sum s (ti) resultará en un campo temporal t
obtenido{ al aplicar la operación Sum t a cada punto en el espacio, ya que
cada punto en el espacio de fi ne un real temporal. De manera similar, Sum
{
t (ti) resultará en un campo temporal t obtenido aplicando la operación
Sum s a cada instante, ya que cada instante de fi ne un campo de reales.
Otras operaciones toman un campo temporal y devuelven un campo no
temporal o un valor temporal. Esto se realiza mediante las operaciones de
agregación global. Suponga que queremos un campo no temporal que
proporcione en cada punto del espacio el valor mínimo de temperatura en
ese punto. Para ello aplicamos la operación FMin que hemos visto en el
Cap.11. En cada punto, esta operación aplica la operación TMin al real
temporal válido en ese punto dando un valor real. Como resultado,
obtenemos un valor de tipo campo (real). De manera análoga, supongamos
que queremos un real temporal que dé en cada instante el valor mínimo de
temperatura en cualquier punto del espacio. Para ello, aplicamos la
operación TMin discutida anteriormente, que en cada instante aplica la F
Min al campo de reales válidos en ese instante dando un valor real. Como
resultado, obtenemos un valor de tipo temporal (real).
Además, deben definirse nuevas operaciones espacio-temporales. Por
ejemplo, la operación AtTGeometry restringe el campo a un subconjunto
dado del cubo espacio-temporal definido por un valor espacial temporal.
En particular, proyectar un campo temporal a un punto temporal
mantendrá sólo los puntos en el campo que pertenecen a la trayectoria en
movimiento del punto, es decir, una línea tridimensional en el cubo. Por
ejemplo, AtTGeometry (Temperature, RouteT1) da como resultado un
campo que define la temperatura durante la trayectoria del camión.
12.3 Implementación de tipos temporales en PostGIS
Los DBMS actuales no admiten tipos temporales. Algunos prototipos

brindan este soporte; el más destacado es Secondo, un sistema de base de
datos diseñado en FernUniversita¨t en Hagen. Secondo puede manejar
objetos en movimiento, es decir, geometrías que cambian continuamente.
En esta sección, mostramos una posible implementación en PostgreSQL /
PostGIS de los tipos temporales que presentamos en Sect.12,2. Nuestra
implementación se basa en el enfoque seguido por Secondo. No obstante,
el lector debe tener en cuenta que estos tipos temporales aún no son
compatibles con PostgreSQL / PostGIS. Los autores de este libro han
explorado esta extensión de una manera prototípica, basada en una
extensión temporal preliminar de PostgreSQL, 2 que de fi ne un tipo de
datos PERIODO y sus operaciones asociadas.
Disponible en http://temporal.projects.pgfoundry.org/
2
Cabe señalar que el soporte temporal se ha introducido en el estándar

SQL: 2011 y se ha implementado en DB2, Oracle y Teradata. Sin embargo,
dicha funcionalidad agrega temporalidad a las tablas, asociando así un
período a cada fila. Sin embargo, para hacer frente a las necesidades del
almacenamiento de datos de trayectoria, necesitamos un enfoque
alternativo que agregue temporalidad a los atributos, asociando así un
período a un valor de atributo.
Tenemos visto que, conceptualmente, un tipo temporal es una
función desde el dominio del tiempo hasta un tipo base o espacial. Por
lo tanto, para cada tipo de datos D, donde D es un tipo base (p. Ej.,
INTEGER, REAL o BOOLEAN) o un tipo espacial (p. Ej., GEOMETRÍA
o sus subtipos), hay tipos temporales asociados TD (P, Q), donde P es
PERIODO o INSTANT y Q es FECHA, HORA o HORA. En otras
palabras, P establece si los valores se registran por intervalos o por
instantes, mientras que Q representa la granularidad a la que se
representan los datos en el período o en el instante P. Por ejemplo, un
tipo T INTEGER (PERIOD, DATE) se puede utilizar para representan
la evolución de los salarios de los empleados que se muestra en la
Fig.12,1. Por otro lado, un valor de tipo T FLOAT (INSTANT, TIME)
puede representar, por ejemplo, que la temperatura fue de 15.5 ° C a las
8:00 am y fue de 17 ° C a las 9:00 am En este caso, puedo
usarFunciones de interpolación (lineal) para calcular el valor de la
temperatura en cualquier momento que no se registre explícitamente.
Como hemos dicho, se supone que la dimensión temporal representa un
tiempo válido.
Los tipos temporales son funciones parciales que pueden estar
indefinidas durante ciertos períodos de tiempo. Usamos el valor NULL
como valor indefinido. Por ejemplo, en la Fig.12,1, el salario de John es
NULO entre 2012-07-01 y 2012-09-30.
Considere, por ejemplo, la siguiente definición de tabla:
CREAR TABLA Empleados (
LLAVE PRIMARIA SSN INTEGER,
Nombre VARCHAR (30),
Apellido VARCHAR (30),
Fecha de nacimiento
FECHA,
SalaryHist T INTEGER (PERIODO, FECHA))
Se puede insertar una tupla en esta tabla de la siguiente manera:

INSÉRTESE EN LOS VALORES DE LOS EMPLEADOS (123456789, 'John',
'Herrero', '1980-01-01', T INTEGER (20 PERÍODOS ('2012-01-01',
'2012-07-01'),
30 PERIODO ('2012-10-01', '2013-01-01')))
El valor de SalaryHist anterior corresponde al valor superior que se

muestra en la Fig. 12,1. Para definir valores de tipos temporales, usamos el
tipo de datos PERIOD definido en la extensión temporal de PostgreSQL
mencionada anteriormente. Los períodos anteriores definen intervalos
cerrados-abiertos. Así, por ejemplo, el valor 20 cubre el período que
comienza el 1 de enero de 2012 hasta el día anterior al 1 de julio de 2012.
Tenga en cuenta que en lugar de una función continua, utilizamos dos
atributos temporales, FromDate y ToDate, para indicar el intervalo de
validez de cada tupla. Tenga en cuenta también que usamos intervalos
cerrados-abiertos.
Mostramos a continuación cómo algunas de las operaciones para tipos

temporales definidas en la Tabla 12,1 se puede expresar extendiendo
PostgreSQL / PostGIS. Por ejemplo, dada la tabla anterior con la única
tupla insertada, la consulta
SELECCIONE DefTime (E.SalaryHist), RangeValues (E.SalaryHist)
DE EMPLEADO mi
devuelve, respectivamente, la matriz de períodos PERIOD ('2012-01-01',

{
'2012-07-01'), PERIOD ('2012-10-01', '2013-01-01') y la matriz de enteros
20,30. Aquí, usamos el tipo ARRAY proporcionado por PostgreSQL. Del}
} {
mismo modo, la consulta
SELECCIONE AtInstant (E.SalaryHist, '2012-03-15'), AtInstant (E.SalaryHist, '2012-07-
15'),
DE EMPLEADO mi
devolverá, respectivamente, los valores 20 y NULL, porque el salario del

empleado no está definido en 2012-07-15. La siguiente consulta
SELECCIONE AtPeriod (E. SalaryHist, PERIOD ('2012-04-01', '2012-11-01'))
DE EMPLEADO mi
devoluciones
T INTEGER (20 PERÍODOS ('2012-04-01', '2012-07-01'),
30 PERIODO ('2012-10-01', '2012-11-01'))
donde los periodos se han proyectado a los intervalos dados en la consulta.

Además, la consulta
SELECCIONE AtMin (E.SalaryHist), AtMax (E.SalaryHist)
DE EMPLEADO mi
dará como resultado

T INTEGER (20 PERÍODOS ('2012-01-01', '2012-
07-01') T INTEGER (30 PERÍODOS ('2012-10-01',
'2013-01-01')
es decir, los valores mínimo y máximo y los intervalos de tiempo en que

ocurrieron.
Nosotros muestre a continuación el uso de operaciones elevadas.
Recuerde que para estas operaciones, la semántica es tal que la operación
sin elevación se aplica en cada instante. Por ejemplo, suponga que se
inserta una segunda tupla en la tabla Empleado de la siguiente manera:
INSERTAR EN LOS VALORES DE LOS EMPLEADOS (T2666, 'María',
'Warner', '1980-01-01', T INTEGER (60 PERÍODOS ('2012-04-
01', '2013-03-01')))
El valor de SalaryHist en la tupla anterior corresponde al valor más bajo

que se muestra en la Fig. 12,1. Entonces, la consulta
SELECCIONE E1.SalaryHist <
E2.SalaryHist DEL EMPLEADO E1,
Empleado E2
DONDE E1.FirstName = 'John' y E2.FirstName = 'María'
da como resultado el valor
T BOOLEANO ( 'Cierto' PERÍODO('2012-04-01', '2012-07-

01') 'Cierto' PERÍODO('2012-10-01', '2013-
01-01'))
Observe que la comparación se realiza solo en los instantes de tiempo que

comparten los dos valores temporales. Del mismo modo, la consulta
SELECCIONAR PROMEDIO (E.SalaryHist)
DE EMPLEADO mi
resultará en el valor
T REAL (20 PERIODO ('2012-01-01', '2013-04-
01')
40 PERIODO ('2012-04-01', '2012-10-01')
60 PERIODO ('2012-10-01', '2012-10-01')
45 PERIODO ('2012-10-01', '2013-01-01')
60 PERIODO ('2013-01-01', '2013-04-01'))
Una representación gráfica de este resultado se muestra en la Fig. 12,2.

Para mostrar las operaciones por tipos espaciales, usaremos la siguiente
tabla, que realiza un seguimiento de las rutas de entrega que siguen los
camiones:
CREAR TABLA Entrega (
TruckId CHAR (6) CLAVE PRIMARIA,
DeliveryDate DATE,
PUNTO T de ruta (INSTANT, TIMESTAMP))
Nosotros inserte ahora dos tuplas en esta tabla, que contienen información
de dos entregas realizadas por dos camiones T1 y T2 el mismo día, 10 de
enero de 2012:
INSERTAR EN LOS VALORES DE ENVÍO ( 'T1', '2012-01-10',
PUNTO T (Punto (0 0) '08:00', Punto (2 2) '08:10', Punto (2 2)
'08:25' ) ) INSÉRTESE EN LOS VALORES DE ENVÍO ( 'T2', '2012-01-10',
PUNTO T (Punto (1 0) '08:05', Punto (3 1) '08:15', Punto (3 2) '08:20' ))
Una representación gráfica de las trayectorias de los dos camiones se

muestra en la Fig. 12,3. Como trabajamos con trayectorias continuas,
asumimos una interpolación lineal entre dos puntos consecutivos
cualesquiera y una velocidad constante.
entre pares de puntos.
Mostramos a continuación ejemplos de operaciones espaciales elevadas.
La siguiente consulta calcula la distancia de los dos camiones en cada
instante:
SELECCIONE Distancia ST (D1.Route,
D2.Route) DESDE Entrega D1, Entrega
D2
DONDE D1.TruckId = T1 Y D2.TruckId = T2
Esta consulta devuelve

T REAL (1 '08:05', 1,5 '08:10', 1,41 '08:25', 1 '08:20' )
cuya representación gráfica se dio en la Fig. 12,4. De manera similar, la

siguiente consulta calcula un búfer de 0,6 km y 10 min alrededor de las
trayectorias:
SELECCIONE Búfer ST (Ruta, 0.6, 0:10)

FROMDelivery
El resultado está compuesto por cilindros espacio-temporales alrededor de

las trayectorias de los camiones. Como hemos visto en la Secta.12,2,
podemos usar esta operación combinada con la operación topológica de
intersección levantada para probar si las rutas de los dos camiones se
cruzan, de la siguiente manera:
SELECT ST Intersects (ST Bu ff er (D1.Route, 0.6, 0:10),
ST Bu ff er (D2.Route, 0.6, 0:10))
FROMDelivery D1, Entrega D2
Finalmente, la siguiente consulta calcula la unión de dos puntos móviles:

SELECCIONE Unión ST (D1.Route,
D2.Route) FROMDelivery D1, Delivery
D2
El resultado de la consulta se da a continuación:

T MULTIPUNTO (
(Punto (0 0) '08:00', Punto (2 2) '08:10', Punto (2 2) '08:25' )
(Punto (1 0) '08:05', Punto (3 1) '08:15', Punto (3 2) '08:20' ))
Para Al implementar campos temporales, utilizamos rásteres temporales

definidos por el tipo T RASTER (P, Q), donde P y Q se definen como antes.
A continuación damos un ejemplo que combina geometrías y rásteres. Para
ello, creamos una tabla LandPlot que describe las parcelas de tierra de la
siguiente manera:
CREAR TABLA LandPlot (
Id INT LLAVE PRIMARIA,
GEOMETRÍA Geom (POLÍGONO),
Tipo de suelo RASTER,
Temp T RASTER (INSTANT, FECHA))
Aquí, el atributo Geom contiene la geometría del terreno, SoilType

contiene un ráster que identifica los tipos de suelo en el terreno y Temp
contiene un ráster temporal que informa las temperaturas en el terreno a
diario. La consulta
SELECCIONE L.Id, AtPeriod (L.Temp, PERIOD ('2012-04-01', '2012-04-04'))
FROMLandPlot L
devuelve para cada terreno un ráster temporal con la temperatura de cada

uno de los 3 días del intervalo. De manera análoga, la siguiente consulta
devuelve para cada parcela de tierra el primer día en el que se informa la
temperatura y el ráster no temporal de ese día:
SELECCIONE L.Id, InitialInstant (L.Temp), InitialValue
(L.Temp) FROMLandPlot L
Podemos ver que las operaciones se aplican a campos temporales de la
misma manera que se aplican a otros tipos de datos temporales. La
siguiente consulta calcula para cada terreno un ráster no temporal que
informa la temperatura promedio durante marzo de 2012 en cada punto
del terreno:
SELECT L.Id, AVG S (AtPeriod (L.Temp, PERIOD ('2012-03-01', '2012-04-01')),
FROMLandPlot L
Aquí, el campo de temperatura está restringido a marzo de 2012 con la

función AtPeriod. Luego, se aplica el AVG S al ráster temporal resultante,
que obtiene en cada punto del espacio la temperatura promedio durante el
mes.
Finalmente, la siguiente consulta selecciona parcelas de tierra con una
temperatura promedio superior a 10 ° C en marzo de 2012:
SELECCIONE L.Id
FROMLandPlot L
DONDE FAvg (Avg S (AtPeriod (T.Temp, PERIOD ('2012-03-01', '2012-04-01')))) > 10
En la consulta anterior, el campo de temperatura, restringido a marzo de

2012 con la operación AtPeriod, se agrega con la operación Avg S, lo que da
como resultado un campo no temporal que informa la temperatura
promedio durante el mes en cada punto. Luego, se aplica la operación de
agregación de campo FAvg para obtener el promedio como valor real, que
luego se compara con 10.
12.4 El almacén de datos de la trayectoria de

Northwind
Nosotros ahora están listos para estudiar cómo un almacén de datos

convencional (o un almacén de datos espaciales) se puede ampliar con
tipos temporales para respaldar el análisis de datos de trayectoria.
Usaremos el caso de estudio de Northwind para presentar los conceptos
principales. Enunciemos el problema.
La compañía Northwind quiere construir un almacén de datos de
trayectoria que realice un seguimiento de las entregas de bienes a sus
clientes para optimizar los costos de envío. Los datos espaciales en el
almacén incluyen la red de carreteras, las ubicaciones de entrega y la
información geográfica relacionada con estas ubicaciones (ciudad, estado,
país y área). Los datos no espaciales incluyen las características de los
camiones que realizan las trayectorias. Además, tenemos las trayectorias
que siguen los camiones, es decir, datos de objetos en movimiento.
Figura12,6 muestra el esquema conceptual que describe el escenario
anterior utilizando el modelo MultiDim, que presentamos en el Cap. 4 y
ampliado para admitir datos espaciales en el Cap. 11 (aunque en su lugar se
podría utilizar cualquier otro modelo conceptual). Para admitir datos
espacio-temporales, ampliamos el modelo MultiDim con tipos espaciales y
tipos temporales.
Nosotros quisiera analizar las entregas por camiones, días, carreteras y
lugares de entrega. Por lo tanto, necesitamos dividir las trayectorias en
segmentos de modo que cada segmento esté relacionado con un solo
camión, día, carretera, ubicación de inicio y
12.4 El almacén de datos de la trayectoria de 4
Figura 12.6 Esquema conceptual del almacén de datos de trayectoria de Northwind
ubicación final. Dado que necesitamos realizar un seguimiento de todos los

segmentos que pertenecen a una única entrega, definimos una dimensión
adicional Entrega que agrupa los datos que pertenecen a cada trayectoria
como un todo.
Como se muestra en la figura, hay un hecho, Segmento, que está
relacionado con cinco dimensiones: Camión, Tiempo, Carretera, Entrega y
Ubicación. El hecho está relacionado con la dimensión Location a través de
dos roles: StartLocation y EndLocation. Las dimensiones se componen de
niveles y jerarquías. Por ejemplo, la dimensión Carretera tiene solo un
nivel y la dimensión Ubicación se compone de cinco niveles, con una
relación padre-hijo de uno a muchos definida entre cada par de niveles.
Los niveles tienen atributos que describen sus instancias o miembros. Por
ejemplo, level Road tiene los atributos RoadId, RoadName y Length. Si un
nivel o un atributo es espacial, tiene una geometría asociada (por ejemplo,
un punto, una línea o una región) que se indica mediante un pictograma,
como se estudió en el capítulo anterior. En nuestro ejemplo, las
dimensiones Carretera y Ubicación son
espacial, y una geometría se asocia con cada nivel en ambas dimensiones.

Por otro lado, StartLocation y EndLocation son atributos espaciales de la
dimensión Entrega, y su geometría es de tipo punto.
Hay siete medidas adjuntas al segmento de hechos: ruta, distancia,
duración, velocidad media, volumen, peso y nivel de riesgo. El primero,
Ruta, mantiene el seguimiento del movimiento del segmento. Es una
medida espacio-temporal de tipo punto temporal, como lo indica el
símbolo 't (•)'. Las otras medidas son numéricas, donde la distancia, la
duración y la velocidad media se calculan a partir de la ruta.
Restricciones topológicas se representan mediante pictogramas en
hechos y en las relaciones entre padres e hijos. Por ejemplo, la restricción
topológica en el segmento de hecho indica que siempre que una carretera y
una ubicación están relacionadas en una instancia de la relación, deben
superponerse. De manera similar, la restricción topológica en la jerarquía
de la dimensión Ubicación indica que una ubicación está incluida en su
Ciudad padre y de manera similar para las otras relaciones padre-hijo en la
jerarquía.
Como se indicó anteriormente, las pistas de movimiento dentro de los
segmentos se mantienen en la medida Ruta, mientras que los datos que
describen las trayectorias completas se mantienen en la dimensión
Entrega. Alternativamente, podríamos haber representado segmentos o
incluso entregas completas en una dimensión. Nuestro modelo es lo
suficientemente flexible como para representar diversas situaciones, donde
las trayectorias se pueden agregar a lo largo de dimensiones espaciales y
alfanuméricas o los hechos se pueden agregar en una dimensión de
trayectoria. La elección entre estas representaciones depende de las
consultas a abordar. De hecho, la complejidad de las consultas y su tiempo
de ejecución dependerán de cuánta información solicitada se precalcula en
medidas, ya que los almacenes de datos están optimizados para agregar
medidas a lo largo de dimensiones. En otras palabras, aunque es posible
agregar datos de dimensiones,
Finalmente, el esquema de la Fig. 12,6 incluye varios campos continuos.
Como se explica en el Cap.11, los campos no temporales se identifican por
el 'f ()' Foto- ,
tograma, mientras que los temporales se identifican por el 'F( )'
pictograma. Allí
son cuatro atributos de campo en el nivel estatal como sigue. Elevación y uso
del suelo
son campos no temporales. El primero podría usarse, por ejemplo, para
analizar la correlación entre la velocidad de las trayectorias y la elevación
(o pendiente), y el segundo para seleccionar trayectorias que comienzan en
un área residencial y terminan en un área industrial. Además, hay dos
campos temporales Temp (temperatura) y Precip (precipitación). Además,
las medidas numéricas se pueden calcular a partir de datos de campo. Por
ejemplo, la medida RiskLevel, que representa el conocimiento de los
expertos en el dominio sobre el riesgo relativo de los segmentos, se puede
calcular a partir de la medida Ruta y los cuatro campos. Por ejemplo, un
segmento con alta velocidad en pendientes descendentes, en áreas
residenciales, con temperaturas heladas o con alta precipitación, tendrá un
alto nivel de riesgo. Los campos también pueden incluirse como medidas
en hechos, aunque esto está fuera del alcance de este capítulo.
12.4 El almacén de datos de la trayectoria de 4
Figura 12.7 Una segmentación alternativa de trayectorias con respecto a las zonas de
entrega
El almacén de datos de la Fig. 12,6 trayectorias de segmentos con

respecto a días, carreteras, camiones, ubicaciones de inicio y ubicaciones
finales. Un esquema alternativo, que se muestra en la Fig.12,7, segmenta
las trayectorias con respecto a las zonas de entrega en las que ocurren.
Tenga en cuenta que, como indica la relación de varios a varios entre zonas
y ciudades, una zona de entrega puede abarcar varias ciudades y una
ciudad se puede dividir en varias zonas de entrega. Observe también que la
granularidad del tiempo en las Figs.12,6 y 12,7 difiere. En el primer caso, la
granularidad es día, aunque mantenemos el seguimiento de movimiento en
la medida de Ruta con una granularidad de marca de tiempo. En el último
caso, relacionamos cada segmento con sus marcas de tiempo inicial y final.
La elección entre los dos esquemas de almacenamiento de datos
alternativos depende de los requisitos de la aplicación y de las consultas
OLAP típicas que se deben abordar.
Cuando las trayectorias se utilizan como medidas, surge el problema de
la agregación. En los ejemplos de las Figs.12,6 y 12,7, mantuvimos la pista
de movimiento
de los segmentos de trayectoria en un punto temporal. Por lo tanto,

podemos agregar dichos segmentos a lo largo de las diferentes
dimensiones. Otro uso de la agregación de trayectorias identifica
trayectorias "similares" y las fusiona en una clase. Esta agregación puede
venir junto con una función agregada, que puede ser la función COUNT en
el caso más simple, aunque se pueden usar otras más complejas. Así,
podemos hacer consultas como “Número total de trayectorias por clase” o
“Enumerar todas las trayectorias similares a la que siguió el camión T1 el
25 de noviembre de 2012”. El principal problema consiste en adoptar una
noción apropiada de similitud de trayectoria, mediante la definición de una
medida de similitud, por ejemplo, una función de distancia. El enfoque
más simple para definir la similitud entre dos trayectorias es verlas como
vectores y usar la distancia euclidiana como medida de similitud. El
problema de esta técnica es que no se puede aplicar fácilmente a
trayectorias que tienen diferente longitud o frecuencia de muestreo, y no es
eficaz en presencia de ruido en los datos. Una forma típica de agregar
trayectorias es agruparlas, considerando diferentes funciones de distancia
u otras características (por ejemplo, el mismo punto de partida, el mismo
punto de finalización, etc.). Descubrir trayectorias con el mismo patrón es
otra forma de agregar trayectorias.
Figura 12.8 Ampliación del almacén de datos de trayectoria de Northwind con

campos globales
En la Fig. 12,6, asociamos los tipos de campo al nivel State. Esto permite
una manipulación más eficiente de los campos cuando el enfoque del
análisis está en el nivel estatal. Sin embargo, como veremos más adelante,
para algunas consultas es necesario mantener los campos generales
cubriendo todo el espacio de interés, sin particiones.
Figura 12,8 extiende nuestro ejemplo con tales campos globales. Por lo
tanto, un campo temporal global como la temperatura puede verse como
un cubo espacio-temporal que
asocia un valor real a cualquier punto dado en el espacio y el tiempo. En
este caso, dichos campos se relacionan con hechos o dimensiones a través
de operaciones espaciales o espacio-temporales.
12.5 Consultar el almacén de datos de trayectoria de Northwind 4
12.5 Consultar el almacén de datos de

trayectoria de Northwind en SQL
Para abordar las consultas al almacén de datos de trayectoria de

Northwind, primero traducimos el esquema conceptual de la Fig. 12,6 en
un esquema de copos de nieve, como se muestra en la Fig. 12,9. Para
expresar nuestras consultas, utilizamos los tipos temporales y sus
operaciones asociadas como se define en la Sect.12,3.
Figura 12.9 Representación relacional del almacén de datos de trayectoria de

Northwind en la Fig. 12,6
Comenzamos con una consulta OLAP convencional.

Consulta 12.1. Total número de segmentos, por carretera, cubiertos por
camiones Volvo en febrero de 2012.
SELECTR.RoadKey, CONTAR(*)
DESDE Segmento S, Carretera R, Hora T, Camión U
WHERES.RoadKey = R.RoadKey Y S.TimeKey = T.TimeKey Y S.TruckKey
= U.TruckKey Y U.TruckBrand = 'Volvo' Y
T.Date >= '2012-02-01' Y T.Fecha < '2012-03-01'
GRUPO POR RoadKey
Esta consulta aborda el segmento de la tabla de hechos y algunas de sus

dimensiones asociadas. La consulta no involucra tipos de datos
temporales, ni siquiera características geométricas de dimensiones
espaciales. La consulta se puede utilizar para identificar los segmentos que
utilizan con más frecuencia los camiones Northwind.
A continuación, damos un ejemplo de una consulta OLAP que involucra
la entrega
dimensión y dos posibles soluciones para ello.
Consulta 12.2. Duración media de las entregas que tienen un segmento
que se iniciaron en la ciudad de Bruselas en el último trimestre de 2012.
SELECCIONAR AVG
(D.TotalDuration)
FROMDelivery D
DONDE EXISTE (
SELECCIONE *
FROMSegment S, StartLocation L, Ciudad C, Hora T
DONDE S.DeliveryKey = D.DeliveryKey Y
S.StartLocationKey = L.LocationKey Y
L.CityKey = C.CityKey Y C.CityName = 'Bruselas' Y
S.TimeKey = T.TimeKey Y T.Quarter = 'Cuarto
trimestre de 2012'
Aquí, para cada instancia de la dimensión Entrega, la consulta interna

verifica que al menos un segmento de la entrega comenzó en la ciudad de
Bruselas y ocurrió en el último trimestre de 2012. Observe que la duración
total de las entregas se calcula previamente en la Entrega dimensión y por
lo tanto es posible aplicarles la función promedio. Si la duración de todas
las entregas debe calcularse a partir de la medida Duración de la tabla de
hechos, entonces la consulta se escribiría de la siguiente manera:
CON DeliveryTotal AS (
SELECTD.DeliveryKey, SUM (Duración) AS TotalDuration
FROMDelivery D, Segment S
DÓNDE D.DeliveryKey =
S.DeliveryKey GRUPO POR D.DeliveryKey)
SELECCIONAR AVG
(Duración total)
DESDEEntregaTotal D
DONDE EXISTE (
SELECCIONE *
FROMSegment S, StartLocation L, Ciudad C, Hora T
S.StartLocationKey = L.LocationKey Y
L.CityKey = C.CityKey Y C.CityName = 'Bruselas' Y
S.TimeKey = T.TimeKey Y T.Quarter = 'Cuarto
trimestre de 2012'
En la versión anterior, una tabla temporal DeliveryTotal calcula la duración

total de una entrega sumando la duración de todos sus segmentos.
Entonces el
el promedio se calcula como en la consulta anterior. Tenga en cuenta que

esta solución se utilizaría si la información de las entregas no se calcula
previamente en la tabla de dimensiones de Entrega, es decir, si el atributo
TotalDuration no está presente en dicha tabla.
Nosotros considere ahora los tipos de datos espaciales y sus operaciones
asociadas, que estudiamos en el Cap. 11. Este tipo de consultas se
denominan consultas SOLAP. Por ejemplo, el predicado ST Intersects se
puede utilizar para probar si dos geometrías se cruzan.
Consulta 12.3. Número de entregas en el último trimestre de 2012, por
cada carretera que cruza Bruselas.
SELECCIONE RoadKey, COUNT (DISTINCT DeliveryKey) AS
NoDeliveries FROMRoad R, Entrega D
DONDE EXISTE (
SELECCIONE *
De ciudad C
DONDE C.CityName = 'Bruselas' Y
ST se cruza (R.RoadGeom, C.CityGeom)) Y
EXISTE (
SELECCIONE *
FROMSegment S, Time T
DONDE S.RoadKey = R.RoadKey Y
S.DeliveryKey = D.DeliveryKey Y
S.TimeKey = T.TimeKey Y T.Quarter = 'Cuarto trimestre de
2012' )
GRUPO POR RoadKey
La primera consulta interna selecciona las carreteras que se cruzan con la

ciudad de Bruselas utilizando el predicado ST Intersects, que determina si
un par de geometrías se cruzan. La segunda consulta interna selecciona las
entregas que tienen un segmento que ocurrió en la ruta en el último
trimestre de 2012. Luego, la consulta externa agrupa para cada ruta todas
las entregas seleccionadas y luego cuenta el número de distintas.
OLAP espacio-temporal explica el caso en el que los objetos espaciales
evolucionan con el tiempo, es decir, involucran tipos espaciales temporales
como se presentó anteriormente. Como ejemplo, la siguiente consulta
incluye la medida Ruta, es decir, la pista de movimiento de un segmento.
Consulta 12.4. Para cada carretera, proporcione la geometría de los
tramos de la carretera en los que pasó al menos una entrega el 1 de mayo
de 2012.
CON SegmentTrajs AS (
SELECCIONE S.SegmentKey, Trayectoria (S.Route) AS
Trayectoria FROMSegment S )
SELECCIONE R.RoadKey, ST Union (S.
Trayectoria) FROMRoad R, SegmentTraj S,
Tiempo T
WHERER.RoadKey = R.RoadKey Y S.TimeKey = T.TimeKey Y T.Date =
'2012-05-01' )
GRUPO POR R.RoadKey
En la de fi nición de la tabla temporal SegmentTrajs, suponemos que existe
una operación Trayectoria (ver Tabla 12,1) que toma como argumento un
punto temporal y devuelve la línea que contiene todos los puntos
atravesados por el primero. Luego, la consulta realiza una unión espacial
sobre todas las geometrías así obtenidas. Observe que una función ST
Union que actúa como una función agregada (por ejemplo, como COUNT)
no está definida por el OGC, pero está disponible en PostGIS.
A continuación, presentamos otro ejemplo de una consulta OLAP
espacio-temporal.
Consulta 12.5. Número de entregas que comenzaron en Bruselas el 1 de
mayo de 2012.
SELECT COUNT (D.DeliveryKey)
FROMDelivery D, Ciudad C
CONVERT (FECHA, D.StartDateTime) = '2012-05-01' Y
ST Intersects (D.StartLocation, C.CityGeom)
Observe que dado que D.StartDateTime devuelve una marca de tiempo, se

aplica la función CONVERT para obtener el día correspondiente. El lector
podría preguntarse a sí mismo que en realidad no se trata de una consulta
espacio-temporal. Sin embargo, esto se debe a que la consulta aprovecha el
hecho de que la hora de inicio y la ubicación de inicio de las trayectorias se
calculan previamente en la dimensión Entrega. Si este no fuera el caso, la
consulta leería
CON DeliveryFull AS (
SELECCIONE D. DeliveryKey, InitialValue (S.Route) AS StartLocation,
InitialInstant (S.Route) AS StartDateTime
FROMDelivery D, segmento S
DONDE D.DeliveryKey = S.DeliveryKey Y NO EXISTE
(SELECCIONAR *
FROMSegmento S1
S1.DeliveryKey = D.DeliveryKey Y InitialInstant
(S1.Route) < InitialInstant (S.Route)))
SELECT COUNT (D.DeliveryKey)
FROMDeliveryFull D, Ciudad C
CONVERT (FECHA, D.StartDateTime) = '2012-05-01' Y
ST Intersects (D.StartLocation, C.CityGeom)
En la de fi nición de la tabla temporal DeliveryFull, las funciones

InitialValue y InitialValue devuelven, respectivamente, el punto inicial y el
instante inicial de la geometría del punto móvil S.Route. La consulta
interna de la definición de la tabla temporal asegura que el segmento S es
el primer segmento de una entrega al verificar que su hora de inicio es la
más pequeña entre todos los segmentos que componen la entrega. Esto se
hace con la ayuda de la función InitialInstant. Finalmente, la consulta
cuenta las entregas que comenzaron en la ciudad de Bruselas el 1 de mayo
de 2012. Dado que el atributo StartDateTime es una marca de tiempo, se
aplica la función CONVERT para obtener el día correspondiente.
Nuestro siguiente ejemplo de consulta involucra el campo LandUse.
Consulta 12.6. Duración media de las entregas que iniciaron en zona

residencial y finalizaron en zona industrial el 1 de febrero de 2012.
SELECCIONE D.TotalDuration
DESDE Entrega D, Ubicación L1, Ubicación L2, Ciudad C1,
Ciudad C2, estado S1, estado S2
DONDE CONVERTIR (FECHA, D.StartDateTime) = '2012-02-
01' Y CONVERTIR (FECHA, D.EndDateTime) = '2012-
02-01' Y
D.StartLocation = L1.LocationGeom Y
D.EndLocation = L2.LocationGeom Y
L1.CityKey = C1.CityKey Y L2.CityKey = C2.CityKey Y
C1.StateKey = S1.StateKey Y C2.StateKey = S2.StateKey Y ST
Intersects (D.StartLocation, At (S1.LandUse,'Residencial')) Y ST
intersecta (D.EndLocation, At (S2.LandUse,'Industrial'))
Dado que se supone que los atributos StartDateTime y EndDateTime son

de tipo timestamp, se utiliza la función CONVERT para obtener las fechas
correspondientes. Luego, la consulta selecciona los miembros L1 y L2 del
nivel de Ubicación correspondientes a las ubicaciones de inicio y
finalización de la entrega, y las uniones posteriores obtienen los estados
correspondientes. Además, la función At (ver Tabla12,1) proyecta los
campos de uso del suelo de los estados correspondientes a los valores de
tipo residencial o industrial. Finalmente, la función ST Intersects asegura
que las ubicaciones de inicio y finalización de la entrega se incluyan en los
rásteres filtrados. Observe que, como es el caso en PostGIS, el predicado ST
Intersects puede calcular no solo si dos geometrías se cruzan, sino también
si se cruzan una geometría y un ráster.
La consulta anterior involucró el campo de uso de la tierra (dividido) en
el estado de nivel. En su lugar, podríamos haber utilizado el campo
LandUse global de la Fig.12,8. En este caso, la consulta se escribiría de la
siguiente manera:
SELECCIONE D.TotalDuration
FROMDelivery D, LandUse
L
DONDE CONVERTIR (FECHA, D.StartDateTime) = '2012-02-
01' Y CONVERTIR (FECHA, D.EndDateTime) = '2012-
02-01' Y
ST intersecta (D.StartLocation, En (L,'Residencial')) Y
ST intersecta (D.EndLocation, At (L,'Industrial'))
En este caso, podemos ver que es más eficiente usar el campo global que el
campo particionado. Sin embargo, hay casos en los que trabajar al revés es
más eficiente.
Tenga en cuenta que la consulta anterior no incluye datos temporales, ya
que no menciona una geometría temporal como la ruta de medida ni un
campo temporal como la temperatura. La siguiente consulta involucra
ambos atributos temporales.
Consulta 12.7. Velocidad promedio y temperatura máxima durante el
segmento, para segmentos de trayectoria ocurridos el 1 de febrero de 2012.
SELECCIONE S.SegmentKey, S.AvgSpeed, TMax (AtMGeometry (E,
S.Route)) FROMSegment S, Time T, Temperature mi
DONDE S.TimeKey = T.TimeKey Y T.Date = '2012-02-01'
En la consulta anterior, usamos el campo de temperatura global que se
muestra en la Fig. 12,8. De lo contrario, necesitaríamos hacer la unión de
los campos en el atributo Temp del nivel State para todos los estados
atravesados por el camión. La función AtMGeometry proyecta el campo
temporal a la pista de movimiento del segmento, lo que da como resultado
un real temporal. En otras palabras, la función calcula la posición del
segmento de la trayectoria en cada instante de tiempo, y luego del campo
válido en ese instante, obtiene la temperatura. Finalmente, la función
TMax obtiene el valor máximo de temperatura durante el segmento.
Nuestro siguiente ejemplo de consulta implica la agregación de campos.
Consulta 12.8. Temperatura promedio por mes y por estado.
Aquí, necesitamos una función auxiliar que, dado un mes y un año,
devuelva el período compuesto por todos los días del mes. La función,
denotada PeriodMonth, se define de la siguiente manera:
CREAR O REEMPLAZAR FUNCIÓN PeriodMonth (Month int, Year int)
DEVOLUCIONES PERIODO COMO $ PeriodMonth $
DECLARAR
PerStart CHAR
(10); PerEnd CHAR
(10);
EMPEZAR
PerStart = CAST ($ 2 como CHAR (4)) '-'
|||| ||
CAST ($ 1 como CHAR (2)) '-
01'; SI $ 1 < 12 ENTONCES
PerEnd = CAST ($ 2 como CHAR (4)) || '-' || CAST ($ 1 + 1 como CHAR
(2)) || '-01';
DE
PerEnd = CAST ($ 2 + 1 como CHAR (4)) '-01-01'
|
TERMINARA SI;
PERIODO DE DEVOLUCIÓN (PerStart,
PerEnd); FINAL;
$ PeriodMonth $ IDIOMA plpgsql;
Entonces, la consulta es la siguiente:

CON Mes COMO (
SELECCIONAR DISTINTO Mes
No, Año FROMTime T)
SELECCIONE S.StateName, M.MonthNo, M.Year,
FAvg (Avg S (AtPeriod (S.Temp, PeriodMonth (M.MonthNo,
M.Year)))) FROM Estado S, mes METRO
Aquí, se supone que el período de tiempo cubierto por la dimensión de

tiempo es el mismo que aquél en el que se define el campo temporal de
temperatura. En la consulta, una tabla temporal Month se define en la
cláusula WITH que contiene todos los meses de la dimensión Time. La
consulta principal comienza combinando cada estado con cada mes. Luego,
el campo de temperatura del estado se proyecta al mes correspondiente
con la función AtPeriod. La función Avg S se usa luego para calcular el
promedio de los valores de temperatura durante el mes en cada punto del
estado, lo que da como resultado un campo no temporal. Finalmente, la
función FAvg obtiene la temperatura promedio sobre el campo no
temporal, que es real.
La siguiente consulta combina un campo y una trayectoria.

Consulta 12.9. Entregas que han recorrido más de 50 km de carreteras a
más de 1.000 m de altitud.
SELECCIONE
D.DeliveryNumber
FROMDelivery D
DONDE (SELECCIONAR SUM (ST Longitud (DefSpace (AtGeometry (
En (T.Elevation, Range (1000,6000)), Trayectoria
(S.Route))))) FROMSegment S, estado T
ST Intersects (T.StateGeom, Trayectoria (S.Route))) > 50
Para En cada entrega, la consulta interna recopila los segmentos que la

componen y los estados atravesados durante el segmento. Esto se hace
verificando en la cláusula WHERE que la geometría del estado y la
trayectoria de la ruta se cruzan. Luego, para cada par de segmento y
estado, el campo de elevación del estado se proyecta al rango de valores
entre 1,000 y 6,000 (se supone que este último es el valor máximo) con la
función At y luego se proyecta a la trayectoria del ruta con función
AtGeometry. La parte de la ruta a más de 1000 m se obtiene mediante la
función DefSpace, y luego se calcula la longitud de esta ruta. La operación
de agregación SUM se utiliza para calcular la suma de las longitudes de
todas las rutas obtenidas y, finalmente, la consulta externa verifica que esta
suma sea mayor que 50.
Las dos consultas siguientes combinan un campo temporal y una
trayectoria.
Consulta 12.10. Entregas que han recorrido más de 50 km en
condiciones de lluvia durante julio de 2013 en Bélgica.
SELECCIONE
D.DeliveryNumber
FROMDelivery D
DONDE (SELECCIONAR SUM (ST Longitud (DefSpace (AtGeometry (
AtPeriod (At (T.Precip, Rango (1100)),
PERÍODO('2013-07-01','2013-08-01')), Trayectoria (Ruta S.)))))
DESDE Segmento S, Estado T, País C
DÓNDE S.DeliveryKey = D.DeliveryKey Y
T.CountryKey = C.CountryKey Y
C.CountryName = 'Bélgica'
ST Intersects (T.StateGeom, Trayectoria (S.Route))) > 50
En la consulta anterior, se supone que las condiciones de lluvia significan

entre 1 mm (lluvia moderada) y 100 mm (lluvia extrema) por hora. Para
cada entrega, la consulta interna recopila los segmentos de composición y
los estados de Bélgica atravesados durante el segmento. Luego, para cada
par de segmento y estado, el campo de precipitación del estado se proyecta
al rango de valores entre
1 y 100 con función At, luego proyectada al mes de julio de 2013
con función AtPeriod, y luego proyectado a la trayectoria de la ruta con
función AtGeometry. La parte de la ruta que satisface las condiciones se
obtiene mediante la función DefSpace, y luego se calcula la longitud de esta
ruta. La operación SUM se usa luego para sumar las longitudes de todas las
rutas obtenidas y, finalmente, la consulta externa verifica que esta suma
sea mayor que 50.
Consulta 12.11. Para cada entrega, indique el tiempo total en el que ha

conducido en condiciones de lluvia a más de 70 km / h.
SELECCIONE D.DeliveryNumber, SUM (Duration (DefTime
(AtPeriod (AtMGeometry (At (T.Precip, Range (1,100),
S.Route)), DefTime (At (Speed (S.Route), Range
(70,150))))) ))
FROMDelivery D, segmento S, estado T
WHERES.DeliveryKey = D.DeliveryKey
Y
ST Intersects (T.StateGeom, Trayectoria
(S.Route)) GROUP BY D.DeliveryNumber
Para Se recopilan cada entrega, los segmentos que la componen y los

estados atravesados durante el segmento. Luego, para cada par de
segmento y estado, el campo de precipitación del estado se proyecta al
rango de valores entre 1 y 100 con la función At, luego se proyecta al punto
móvil con la función AtMGeometry, y luego se proyecta al período de
tiempo en cuya velocidad de trayectoria estuvo entre 70 y 150 km / h con
función AtPeriod. La función DefTime calcula el período de tiempo durante
el cual la ruta cumple las condiciones y luego se calcula la duración de este
período. Finalmente, la operación SUM se utiliza para sumar las
duraciones de todos los períodos obtenidos.
12.6 Resumen
Tenemos discutieron las técnicas de almacenamiento de datos que

aplicadas a los datos de trayectoria ayudan a mejorar el proceso de toma de
decisiones. Para ello, primero definimos tipos temporales, que capturan la
variación de un valor a lo largo del tiempo. La aplicación de tipos
temporales a datos espaciales conduce a la noción de tipos espaciales
temporales, que proporcionan una visión conceptual de las trayectorias.
Finalmente, la aplicación de tipos temporales a tipos de datos de campo
produce tipos de datos de campo espaciotemporales, que modelan campos
continuos temporales. En el nivel lógico, estudiamos cómo se pueden
implementar estos tipos de datos conceptuales en PostGIS. Presentamos
un caso concreto que amplía el almacén de datos de Northwind con datos
de trayectoria y mostramos cómo consultar este almacén de datos
utilizando PostGIS extendido con tipos temporales de diferentes tipos.
Una perspectiva general del estado actual del arte en la gestión de

trayectorias se puede encontrar en los libros [173,240]. Se puede encontrar
un estado del arte en almacenamiento de datos espacio-temporales, OLAP
y minería en [70]. Este capítulo se basa en trabajos de investigación
previos sobre almacenamiento de datos espacio-temporales y campos
continuos realizados por los autores [212, 213].
12.8 Preguntas de 5
El sistema de tipos de datos para tipos temporales sigue el enfoque de
[75]. El sistema Secondo desarrollado por Gu¨ting et al. se describe en
[233]. Se propone una extensión SQL para datos espacio-temporales en
[223]. La vista de campos continuos como cubos se introdujo en [69]. El
almacén de datos de trayectoria de GeoPKDD, su proceso ETL asociado y el
problema de la doble contabilización durante la agregación se estudian en
[151]. En [129, 161]. Las herramientas de análisis para almacenes de datos
de trayectoria se pueden encontrar en [167]. En [222], mientras que en [7].
12.1 ¿Qué son los objetos en movimiento? ¿En qué se diferencian de los
objetos espaciales?
12.2 Dé ejemplos de diferentes tipos de objetos en movimiento, y para
cada uno de estos tipos, ilustre un escenario en el que el análisis de
ellos es importante.
12.3 ¿Qué es una trayectoria?
12.4 Analice los diferentes criterios que se pueden utilizar para
segmentar el movimiento. ¿Cómo impactan los requisitos de
análisis en esta segmentación?
12.5 ¿Cuál es la diferencia entre trayectorias continuas y discretas?
12.6 Defina los términos bases de datos de trayectoria y almacenes de
datos de trayectoria. Mencione las principales diferencias entre los
dos conceptos.
12.7 ¿Qué son los tipos temporales? ¿Cómo se construyen?
12.8 Defina la hora válida y la hora de la transacción.
12.9 Dé un ejemplo de un tipo de base temporal, un tipo espacial
temporal y un tipo de campo temporal.
12.10 Dé ejemplos de operaciones asociadas con cada uno de los tipos
temporales en la pregunta anterior.
12.11 Explique por qué se deben eliminar las operaciones tradicionales
para los tipos temporales. Ilustre esto con ejemplos.
12.12 Dé una pista sobre cómo se pueden implementar los tipos
temporales en una plataforma como PostGIS. ¿En qué se diferencia
esta implementación de la definición abstracta de tipos temporales?
12.13 Analice cómo se pueden agregar tipos temporales a un esquema
multidimensional.
12.14 Analice las implicaciones de incluir trayectorias como dimensiones
o medidas en un almacén de datos.
12.15 ¿Qué significa el término similitud de trayectorias? Indique por qué
este concepto es importante en el contexto del almacén de datos.
12.16 Comente dos formas diferentes de incluir tipos de campo en un
esquema multidimensional. Proporcione ejemplos de consultas que
aprovechen una representación sobre la otra.
12.9 Ejercicios
12.1 Considere la aplicación de la compañía de trenes descrita en el Ej. 3.2

y cuyo esquema conceptual multidimensional se obtuvo en Ex. 4.3.
Agregue datos espacio-temporales a este esquema para transformarlo
en un almacén de datos de trayectoria. Debe analizar las
dimensiones, hechos y medidas, y definir cuál de ellos puede
ampliarse con características espacio-temporales.
12.2 Transformar el esquema conceptual obtenido como solución para Ej.
12,1 en uno relacional. Este esquema debe corresponder al esquema
relacional sin características espacio-temporales obtenido en Ex.5.3.
12.3 Escribir en SQL las siguientes consultas sobre el esquema relacional
obtenido en Ex. 12,2:
(a) Indique el número de viaje, origen y destino de los viajes que
contengan tramos con una duración superior a 3 hy cuya longitud
sea inferior a 200 km.
(b) Indique el número de viaje, el origen y el destino de los viajes que
contengan al menos dos segmentos atendidos por trenes de
diferentes constructores.
(c) Indique el número de viajes que atraviesan al menos tres
ciudades en menos de 2 h.
(d) Indique el número total de viajes que cruzan al menos dos
fronteras de países en menos de 4 h.
(e) Proporcione la velocidad promedio por constructor de trenes.
Esto debe calcularse tomando la suma de las duraciones y
longitudes de todos los segmentos con el mismo constructor y
obteniendo el promedio. El resultado debe ordenarse por
velocidad media.
(f) Para cada número posible de segmentos totales, indique el
número de viajes en cada grupo y la duración media, ordenados
por número de segmentos. El resultado debería verse como (5,
50, 85; 4, 30, 75;...), Lo que significa que hay 50 viajes con 5
segmentos con una longitud promedio de 85 km, 30 viajes con 4
segmentos de longitud promedio de 75 km, y así sucesivamente.
(g) Proporcione el número de viaje y las estaciones de origen y
destino para viajes en los que al menos un segmento del viaje
recorra al menos 100 km dentro de Alemania.
12.4 Considere una aplicación que monitorea la calidad del aire midiendo
los valores de un conjunto de contaminantes (como partículas o
dióxido de azufre) en un número fijo de estaciones. Las medidas se
recolectan cada hora o diariamente y se expresan tanto en unidades
tradicionales (como microgramos por metro cúbico, o partes por
millón) o usando un índice de calidad del aire, que en Europa tiene 5
niveles usando una escala de 0 (muy bajo) a mayor que 100 (muy
alto). Las estaciones suelen estar ubicadas junto a las carreteras y
obviamente ubicadas en distritos. Finalmente, también hay datos de
campo correspondientes al uso del suelo y temperatura.
12.9 5
Figura 12.10 Un esquema multidimensional para analizar la calidad del aire
El esquema conceptual multidimensional de esta aplicación se

muestra en la Fig. 12.10. Traduzca el esquema a un esquema lógico.
(a) Para contaminantes pertenecientes a la categoría orgánica, dar el
valor máximo por estación y mes.
(b) Para estaciones ubicadas en la Autostrada del Sole, dan los
valores promedio de plomo registrados en el último trimestre de
2010.
(c) Para estaciones ubicadas a una distancia máxima de 1 km de la
Autostrada del Sole, dan los valores promedio de plomo
registrados en el último trimestre de 2010.
(d) Para zonas con al menos 20% de uso de suelo industrial,
proporcione el valor promedio de monóxido de carbono el 1 de
febrero de 2012.
(e) Carreteras ubicadas en zonas industriales, de manera que la
temperatura promedio en 2012 a lo largo de la carretera fue
superior a 20◦C.
(f) Temperaturas máximas por tipo de uso del suelo en 2012.
(g) Temperaturas máximas en 2012 en estaciones donde los
contaminantes orgánicos superaron el límite más de cinco veces.
12.6 Considere el almacén de datos de trayectoria alternativo de

Northwind que se muestra en la Fig. 12,7, que se obtiene dividiendo
las entregas en zonas en lugar de carreteras. Traducir el esquema
conceptual a uno lógico.
(a) Para cada camión, indique el número total de horas de servicio por
país.
(b) Para cada entrega y cada zona, indique el tiempo total conducido
en la zona y la velocidad media y máxima dentro de la zona.
(c) Enumere las entregas que comenzaron y finalizaron en la misma
zona y que han pasado por una zona diferente a la anterior.
(d) Indique las entregas, junto con su duración, para las entregas que
comenzaron en una zona que pertenece a dos estados diferentes y
terminaron en una zona que pertenece exactamente a un estado.
(e) Total número de entregas que se iniciaron en una zona que
contiene la ciudad de Bruselas, se condujeron durante al menos 2
h dentro de Francia y finalizaron en una zona perteneciente a
Amberes.
(f) Para cada entrega y cada zona, indique el número total de horas
que la entrega condujo dentro de la zona en condiciones de lluvia
y a más de 20 ° C.
(g) Camiones que condujeron en marzo de 2012 en zonas tales que
más del 50% de su superficie se encuentra a más de 1.000 m
sobre el nivel del mar.
Capítulo 13
Nuevas tecnologías de almacenamiento
de datos
Big data se refiere a grandes colecciones de datos que pueden no estar

estructurados o pueden crecer tanto y a un ritmo tan rápido que es difícil
administrarlos con sistemas de base de datos estándar o herramientas de
análisis. Ejemplos de big data incluyen registros web, etiquetas de
identificación por radiofrecuencia, redes de sensores y redes sociales, entre
otros. Se ha informado al momento de escribir este libro que Twitter y
Facebook agregan y procesan 7 y 10 terabytes de datos, respectivamente,
todos los días. Aproximadamente el 80% de estos datos no están
estructurados y el 90% de ellos se han creado en los últimos 2 años. La
gestión y el análisis de estas enormes cantidades de datos exigen nuevas
soluciones que vayan más allá de los procesos tradicionales o herramientas
de software. Todo esto tiene grandes implicaciones en la forma en que se
llevará a cabo la práctica del almacenamiento de datos en el futuro. Por
ejemplo, el análisis de big data requiere en muchos casos que la latencia de
los datos (el tiempo transcurrido entre el momento en que se recopilan
algunos datos y la acción basada en dichos datos) se reduzca
drásticamente. Por tanto, se deben desarrollar técnicas de gestión de datos
casi en tiempo real. Además, es posible que sea necesario consultar fuentes
de datos externas como la web semántica.
La tecnología ha comenzado a dar respuestas a los desafíos introducidos
por
Big Data: procesamiento paralelo masivo, sistemas de bases de datos de
almacenamiento de columnas y sistemas de bases de datos en memoria
(IMDBS) son algunas de estas respuestas que analizaremos en este
capítulo. En la secc.13,1, presentamos el framework MapReduce y su
implementación más popular, Apache Hadoop. En la secc.13,2, estudiamos
Hive y Pig Latin, dos lenguajes de alto nivel que facilitan la escritura del
código MapReduce. Luego estudiamos dos arquitecturas que se utilizan
cada vez más en el almacenamiento de datos: los sistemas de bases de
datos de almacenamiento de columnas (Sect.13,3) y las IMDBS (Sect. 13,4).
Para dar una imagen completa, en la Secta.13,5 nosotros describa
brevemente varios sistemas de bases de datos que explotan las
arquitecturas anteriores. Concluimos el capítulo con un estudio sobre el
almacenamiento de datos en tiempo real (Sec.13,6) y el paradigma de
extracción, carga y transformación (ELT), que desafía el proceso ETL

tradicional (Sect. 13,7). Estos nuevos datos

54655-6 13,
5 13 nuevas tecnologías de
Los paradigmas de almacenamiento se basan en las tecnologías que

estudiamos en la primera parte del capítulo.
13.1 MapReduce y Hadoop
MapReduce es un marco de procesamiento desarrollado originalmente por

Google para realizar búsquedas web en una gran cantidad de máquinas de
productos básicos. MapReduce se puede implementar en muchos idiomas
sobre muchos formatos de datos. Trabaja en el concepto de dividir y
conquistar, dividiendo una tarea en trozos más pequeños y procesándolos
en paralelo sobre una colección de máquinas idénticas (un grupo). Los
datos de cada procesador normalmente se almacenan en el sistema de
archivos, aunque los datos de los sistemas de gestión de bases de datos
(DBMS) son compatibles con varias extensiones, como HadoopDB. Un
programa MapReduce consta de dos fases, a saber, Map y Reduce, que se
ejecutan en paralelo en servidores de productos básicos agrupados, como
veremos a continuación.
Entre las muchas implementaciones de MapReduce, la más popular es
Hadoop, un marco de código abierto escrito en Java. Tiene la capacidad de
manejar datos estructurados, no estructurados o semiestructurados
utilizando hardware básico, dividiendo una tarea en fragmentos paralelos
de trabajos y datos. Hadoop se ejecuta en su sistema de archivos
distribuido (HDFS), pero también puede leer y escribir en otros sistemas
de archivos. Hadoop usa bloques (típicamente de 128 MB) para almacenar
archivos en el sistema de archivos. Un bloque de Hadoop puede constar de
muchos bloques del sistema operativo subyacente. Además, los bloques se
pueden replicar en varios nodos diferentes. Por ejemplo, block1 se puede
almacenar en node1 y node3, block2 en node2 y node4, y así
sucesivamente. Hay dos piezas principales de software que manejan los
trabajos de MapReduce:
• El rastreador de trabajos recibe todos los trabajos de los clientes,
programa las tareas de Map y Reduce a los rastreadores de tareas
apropiados, monitorea las tareas que fallan y las reprograma a
diferentes nodos del rastreador de tareas. Existe un rastreador de
trabajos en cada clúster de Hadoop.
• Los rastreadores de tareas son los módulos que ejecutan el trabajo. Hay
muchos rastreadores de tareas en un clúster de Hadoop para
administrar el paralelismo en las tareas de Map y Reduce.
Continuamente envían mensajes al rastreador de trabajos para que este
sepa que están vivos y solicitando una tarea.
El proceso y los elementos involucrados en un trabajo de MapReduce se
pueden describir sucintamente de la siguiente manera:
• El programa MapReduce le dice a un cliente de trabajo que ejecute un
trabajo MapReduce. El cliente de trabajo envía un mensaje a un
rastreador de trabajos y obtiene una identificación para el trabajo.
• El cliente del trabajo copia los recursos del trabajo (por ejemplo, un
archivo .jar) en el sistema de archivos compartidos, generalmente
13.1 MapReduce y Hadoop 5
HDFS.
• El cliente de trabajo envía una solicitud al rastreador de trabajos para
iniciar el trabajo. El rastreador de trabajos calcula las formas de dividir
los datos para poder enviar cada fragmento de trabajo a un proceso de
mapeador diferente para maximizar el rendimiento.
p1, 100 (p1, 100)

p2, 200 (p2, 200)
p1, 200 (p1, 200)
p1, 300 (p1, 300)
... ... (p1, [100, 200,
300, 300])
(p2, [200, 200])
p1, 300 (p1, 300) (p3, [300])
p2, 200 (p2, 200) (p4, [200, 300])
p4, 200 (pág. 4, 200) ...
p3, 300 (p3, 300)
... ...
p2, 200 (p2, 200) (p1, [200])

p3, 500 (p3, 500) (p2, [200])
p1, 200 (p1, 200) (p3, [500])
p4, 100 (pág. 4, 100) (p4, [100])
... ... ...
(p1, 300)
(p2, 200)
(p3, 300)
(pág. 4, 300)
...
(p1, 200)
(p2, 200)
(p3, 500)
(pág. 4, 100)
...
Reducir con
MapShuffle función MAX
Figura 13.1 Un proceso MapReduce para productos
• El rastreador de trabajos envía una tarea de mapa o una tarea de

reducción a un rastreador de tareas para su ejecución. Los rastreadores
de tareas, basados en el ID del trabajo, recuperan los recursos del
trabajo del sistema de archivos distribuidos.
• Finalmente, los rastreadores de tareas inician una máquina virtual Java
con un proceso secundario que ejecuta el código Map o Reduce.
Figura 13,1 muestra un ejemplo de cómo funciona MapReduce. Tenga en
cuenta que los pedidos de la base de datos Northwind provienen de
muchas fuentes, cada una de un país. Nos interesa analizar las ventas de
productos. Los archivos de este ejemplo contienen pares de la forma
(ProductKey, Quantity). En una fase de mapa, la entrada se divide en una
lista de pares clave-valor con la clave de producto como clave y la cantidad
como valor. A continuación, esta lista se envía como entrada a la fase
denominada Shu ffl e, en la que se ordena de forma que se agrupen los
valores con la misma clave de producto. La salida de la fase shu ffl e es una
13.1 MapReduce y Hadoop 5
colección de tuplas de la forma (clave, lista de valores). Esto se envía a una
fase Reducir donde se pueden realizar muchas operaciones diferentes
como promedio, suma o recuento. Dado que los pares de lista de claves son
independientes entre sí,
La siguiente tabla resume el formato de entrada y salida de las fases de
un proceso MapReduce:
Aporte Producció
n
Mapa (k1, v1) (Lista (k2,
Shu ffl (Lista (k2, v2))
e v2)) (k2, Lista
(k2, Lista (v2))
Reduci
(v2)) (Lista (k3,
r
v3))
13.2 Idiomas de alto nivel para Hadoop
Usar Hadoop no es fácil para los usuarios finales que no están

familiarizados con MapReduce. Los usuarios necesitan escribir código
MapReduce incluso para tareas simples como contar o promediar. Una
solución para esto es utilizar lenguajes de alto nivel, que permiten a los
programadores trabajar a un nivel más alto de abstracción que en Java u
otros lenguajes de nivel inferior compatibles con Hadoop. Los lenguajes
más utilizados son Hive y Pig Latin. Ambos se traducen en trabajos de
MapReduce, lo que da como resultado programas mucho más pequeños
que los equivalentes de Java. Además, estos lenguajes se pueden ampliar,
por ejemplo, escribiendo funciones definidas por el usuario en Java. Esto
puede funcionar al revés: los programas escritos en lenguajes de alto nivel
también se pueden incrustar en otros lenguajes.
13.2.1 Colmena
Hive, desarrollado en Facebook, trae los conceptos de tablas, columnas,
particiones y SQL a la arquitectura de Hadoop, manteniendo la
extensibilidad y fl exibilidad de Hadoop. Hive organiza los datos en tablas y
particiones. Al igual que en los sistemas relacionales, las particiones se
pueden definir de acuerdo con intervalos de tiempo, lo que permite a Hive
podar los datos mientras procesa una consulta. Además, Hive proporciona
un dialecto SQL llamado Hive Query Language (HiveQL) para consultar
datos almacenados en un clúster de Hadoop. HiveQL no es solo un
lenguaje de consulta, sino también un lenguaje de definición y
manipulación de datos. El lenguaje de definición de datos se utiliza para
crear, modificar y eliminar bases de datos, tablas, vistas, funciones e
índices. El lenguaje de manipulación de datos se utiliza para insertar,
actualizar y eliminar a nivel de tabla; estas operaciones no se admiten a
nivel de fila.
El modelo de datos de Hive incluye tipos de datos primitivos como
BOOLEAN y
INT y tipos de datos de recopilación como STRUCT, MAP y ARRAY. Los
tipos de datos de colección permiten, por ejemplo, representar relaciones
de varios a varios, evitando las relaciones de clave externa entre tablas.
Por otro lado, introducen la duplicación de datos y no refuerzan la
integridad referencial. Como ejemplo, mostramos a continuación una
representación simplificada de la tabla Empleados de la base de datos
Northwind en la Fig.2.4, donde los atributos que componen una dirección
completa se almacenan en una ESTRUCTURA y el atributo Territorios es
un ARRAY que contiene el conjunto de nombres de territorios con los que
está relacionado el empleado. Hive no tiene control sobre cómo se
almacenan los datos y admite diferentes formatos de archivo y registro. El
esquema de la tabla se aplica mientras se leen los datos del
almacenamiento, implementando lo que se conoce como esquema al leer.
El siguiente ejemplo incluye la definición de formato de archivo
(TEXTFILE en este caso) y los caracteres delimitadores necesarios para
analizar cada registro:
13.1 MapReduce y Hadoop
CREAR TABLA Empleados (
5
EmployeeID INT, nombre STRING,
13.2 Idiomas de alto nivel para Hadoop 5
Dirección STRUCT<Calle: STRING, Ciudad: STRING, Región:
STRING, Código postal: STRING, País: STRING>,
Territorios
FORMACIÓN<CUERDA> ) FORMATO
DE FILA
CAMPOS DELIMITADOS TERMINADOS POR
',' ARTÍCULOS DE LA COLECCIÓN
|
TERMINADOS POR '' LÍNEAS TERMINADAS
\
POR ' norte'
ALMACENADO COMO TEXTFILE;
HiveQL permite implementar las operaciones relacionales típicas. La

siguiente consulta realiza una proyección sobre los atributos Nombre y
Ciudad:
SELECCIONE Nombre,
Dirección.Ciudad DE
EMPLEADOS;
Una operación de selección que obtiene empleados relacionados con más

de cuatro territorios se expresa de la siguiente manera:
SELECCIONE *
DE EMPLEADOS
DONDE Tamaño (Territorios) > 4;
HiveQL admite diferentes operaciones de unión, como INNER JOIN,

OUTER JOIN y LEFT SEMI JOIN, entre otras. A continuación, unimos las
tablas Empleados y Pedidos:
SELECCIONE *
FROMEmployees E JOIN Órdenes O ON E.EmployeeID = O.EmployeeID
HiveQL también admite otras cláusulas similares a SQL, por ejemplo,

GROUP BY, HAVING y ORDER BY.
Hive también admite cálculos que van más allá de los lenguajes
similares a SQL, por ejemplo, la generación de modelos de aprendizaje
automático. Para ello, Hive proporciona construcciones de lenguaje que
permiten a los usuarios conectar sus propios scripts de transformación en
una declaración SQL. Esto se hace a través de las palabras clave MAP,
REDUCE, TRANSFORM, DISTRIBUTE BY, SORT BY y CLUSTER BY
en las extensiones SQL. Como ejemplo, mostramos cómo podemos escribir
un programa Hive para contar las ocurrencias de productos en un archivo
de entrada, como en el ejemplo de la Fig.13,1. Esta es una variante del
ejemplo típico de recuento de palabras:
CREAR MESA Productos (contenido
CUERDA); DESDE (MAPA
Productos.Contenido
UTILIZANDO 'tokenizerScript' COMO ID de
producto, recuento de productos
CLUSTER POR ProductID) mapOut
REDUCIR mapOut.ProductID,
mapOut.Count USANDO 'countScript' AS
ProductID, Count;
Los scripts tokenizerScript y countScript se pueden implementar en

cualquier lenguaje, como Python o Java. La secuencia de comandos
anterior produce una tupla para cada producto nuevo en la entrada; el
último script cuenta el número de ocurrencias
de cada producto. La cláusula CLUSTER BY le dice a Hive que distribuya la
salida del mapa (mapOut) a los reductores mediante hash en ProductID.
13.2.2 Jerga
Pig es un lenguaje de flujo de datos de alto nivel para consultar datos
almacenados en HDFS. Fue desarrollado en Yahoo! Investigue y luego se
trasladó a la Apache Software Foundation. Hay tres formas diferentes de
ejecutar Pig: (a) como un script, simplemente pasando el nombre del
archivo de script al comando Pig; (b) usando la línea de comando gruñido;
y (c) llamar a Pig desde Java en su forma incrustada. Un programa Pig
Latin es una colección de declaraciones, que pueden ser una operación o
un comando. Por ejemplo, la operación LOAD con un nombre de archivo
como argumento carga datos de un archivo. Un comando podría ser un
comando HDFS usado directamente dentro de Pig Latin, como el comando
ls para listar todos los archivos en el directorio actual. La ejecución de una
declaración no necesariamente da como resultado un trabajo que se ejecuta
en el clúster de Hadoop.
Pig no requiere información de esquema, lo que lo hace adecuado para
datos no estructurados. Si se dispone de un esquema de los datos, Pig lo
utilizará, tanto para la comprobación de errores como para la
optimización. Sin embargo, si no hay ningún esquema disponible, Pig
seguirá procesando los datos haciendo las mejores conjeturas que pueda.
Tipos de datos de cerdo
puede ser de dos tipos. Los tipos escalares son los tipos de datos
habituales, como INTEGER, LONG, FLOAT y CHARARRAY. Por otro lado,
se admiten tres tipos de tipos complejos en Pig, a saber, TUPLE, BAG y
MAP, donde el último
es un conjunto de pares clave-valor. Por ejemplo, según la disponibilidad
del esquema, podemos cargar los datos de los empleados de varias formas
Empleados = CARGAR 'Empleados' AS (Nombre: chararray, Ciudad: chararray,
Edad: int); Empleados = CARGAR'Empleados' AS (nombre, ciudad, edad);
Empleados = CARGAR 'Empleados';
correspondiente, respectivamente, a si hay esquema explícito y tipos de

datos, esquema explícito sin tipos de datos o sin esquema.
Como ejemplo, mostramos cómo se pueden implementar las
operaciones de álgebra relacional en Pig, utilizando la base de datos
Northwind de la Fig. 2.4. Empezamos por la proyección. Supongamos que
hemos cargado la tabla Empleados en el archivo de texto
EmployeeLoad.txt:
EmployeeLoad = LOAD '/user/northwind/Employees.txt' COMO
(EmployeeID, LastName, FirstName, Title, ...,
PhotoPath); EmployeeData = PARA CADA EmployeeLoad GENERAR
EmployeeID, LastName, FirstName;
DUMPEmployeeData;
STOREEmployeeData EN '/ inicio / resultados / proyectado';
La mayoría de los pasos se explican por sí mismos. La instrucción

GENERATE proyecta los primeros tres atributos en el archivo
Employees.txt almacenado en la variable EmployeeLoad.
Una selección se codificaría como:

EmployeeThree = FILTRAR EmployeeLoad POR EmployeeID
== '3'; DUMPEmployeeThree;
La agregación también se admite en Pig a través de la operación GROUP

BY. Suponga que ya tenemos cargada la relación EmployeeLoad y
queremos calcular agregados a partir de estos datos. Para esto, tenemos
que agrupar las filas en cubos. Sobre estos datos agrupados, podemos
ejecutar las funciones agregadas. Por ejemplo, podemos agrupar los datos
de los empleados por Nombre:
byFirstName = GROUP EmployeeLoad BY FirstName;
El resultado de esta operación es una nueva relación con dos columnas:

una denominada grupo y la otra con el nombre de la relación original. El
primero contiene el esquema del grupo, en nuestro caso una columna de
tipo CHARARRAY que contiene todos los primeros nombres de la tabla
original. Se puede acceder directamente a esta columna como
group.FirstName. La segunda columna tiene el nombre de la relación
original y contiene una bolsa de todas las filas en dicha relación que
coinciden con el grupo correspondiente, es decir, las filas correspondientes
a los empleados con el mismo primer nombre.
Luego, los resultados se pueden procesar utilizando las funciones
agregadas clásicas, por ejemplo, COUNT, y el operador FOREACH, que
realiza un bucle sobre cada bolsa, de la siguiente manera:
FirstNameCount = FOREACH byFirstName GENERAR
GROUP AS FirstName COUNT
(EmployeeLoad),
Nosotros concluya con un ejemplo de una operación de combinación.

Queremos unir los archivos que almacenan pedidos y empleados. La unión
debe realizarse sobre dos atributos, el DNI del empleado y el código postal,
a fin de obtener los empleados que manejaron los pedidos enviados al lugar
donde viven. Finalmente, se realiza una proyección:
Empleados = CARGAR '/user/northwind/Employees.txt'
AS (EmployeeID, LastName, ...,
PhotoPath);
Pedidos = CARGAR './northwind/Orders.txt' COMO
(OrderID, CustomerID, EmployeeID, ..., ShipCountry);
Joined = JOIN Employees BY (EmployeeID, Código postal),
Pedidos POR (EmployeeID,
ShipPostalCode); Proyectado = PARA CADA UNIDO
GENERAR
Empleados :: EmployeeID, Empleados :: PostalCode, Pedidos ::
CustomerID;
DUMPProjected;
Las dos primeras declaraciones cargan los dos archivos en dos variables,
Empleados y Pedidos. La instrucción JOIN BY realiza la unión, de manera
similar a SQL, y GENERATE realiza la proyección.
Las combinaciones externas izquierda y derecha se realizan de manera
similar, agregando las palabras clave LEFT OUTER y RIGHT OUTER,
respectivamente, después de JOIN BY
cláusula. Por ejemplo, en la consulta anterior, escribiríamos JOIN
Employees BY (EmployeeID, PostalCode) LEFT OUTER.
13.3 Sistemas de bases de datos de almacenamiento

de columnas
Hasta ahora, hemos asumido arquitecturas DBMS con el típico

almacenamiento orientado a registros, donde los atributos de un registro
se colocan de forma contigua en las páginas del disco. Así, una página de
disco contiene un cierto número de tuplas de base de datos, a las que en el
momento de ser consultadas se accede ya sea de forma secuencial o
mediante algunos de los índices estudiados en el Cap.7. Estas arquitecturas
son apropiadas para sistemas OLTP. Para los sistemas orientados a la
consulta ad hoc de grandes cantidades de datos (como en OLAP), otras
estructuras pueden funcionar mejor, por ejemplo, bases de datos de
almacenamiento de columnas, donde los valores para cada columna (o
atributo) se almacenan contiguamente en las páginas del disco, como que
una página de disco contendrá varias columnas de base de datos. Por lo
tanto, un registro de base de datos se dispersa en muchas páginas de disco
diferentes. Estudiamos esta arquitectura a continuación.
Figura 13,2a muestra la organización de almacenamiento en filas, donde
los registros se almacenan en las páginas del disco. Figura13,2b muestra la
alternativa de almacenamiento de columnas. En la mayoría de los sistemas,
una página contiene una sola columna. Sin embargo, si una columna no
cabe en una página, se almacenará en tantas páginas como sea necesario.
Al evaluar una consulta sobre una arquitectura de almacenamiento de
columnas, un DBMS solo necesita leer los valores de las columnas
involucradas en la consulta, evitando así cargar en la memoria atributos
irrelevantes. Por ejemplo, considere una consulta de almacén de datos
típica sobre el almacén de datos de Northwind de la siguiente manera:
SELECTCustomerName, SUM (SalesAmount)
FROMVentas S, Cliente C, Producto P, Hora T, Empleado E
WHERES.CustomerKey = C.CustomerKey Y
S.ProductKey = P.ProductKey Y S.TimeKey = T.TimeKey Y
S.EmployeeKey = E.EmployeeKey Y
P. Discontinuado = 'sí' Y T. Año = '2012' Y E.City = 'Berlina'
GRUPO POR C.Nombre del cliente
Dependiendo de la estrategia de evaluación de la consulta, la consulta

anterior puede requerir el acceso a todas las columnas de todas las tablas
en la cláusula FROM, por un total de 51 columnas. El número de columnas
puede aumentar considerablemente en un almacén de datos empresarial
del mundo real. Sin embargo, solo se necesitan 12 de ellos para evaluar esta
consulta. Por lo tanto, un DBMS orientado a filas leerá en la memoria
principal una gran cantidad de columnas que no contribuyen al resultado y
que probablemente serán eliminadas por un optimizador de consultas. Por
el contrario, un sistema de base de datos de almacenamiento de columnas
solo buscará las páginas que contienen las columnas que realmente se
utilizan en la consulta. Además, es probable que los valores de E.City,
T.Year y P.Discontinued quepan en la memoria principal.
13.3 Sistemas de bases de datos de almacenamiento de columnas 515
C1 C2 C3 C4 C5 C6 C7 C8C1 C2 C3 C4 C5 C6 C7 C8
filas
...
Página 1 Página n
B
C1 C2 C3 C4 C5 C6 C7 C8
...
paginas
Figura 13.2 Sistemas de base de datos de almacenamiento en filas (a) versus

almacenamiento en columnas (b)
Ahorrar espacio, los sistemas de bases de datos de almacenamiento de

columnas normalmente almacenan columnas en páginas en forma
comprimida. Por ejemplo, considere la parte de la tabla de hechos de
ventas, que se muestra en la Fig.13,3una. Figura13,3b – d muestra un
posible esquema de codificación para las columnas EmployeeKey,
CustomerKey y ProductKey, respectivamente. La compresión se basa en la
codificación de longitud de ejecución, ya discutida en el Cap.7. Por
ejemplo, la Fig.13,3b muestra una tabla de tres columnas, con atributos f,
vyl, donde f indica el primero de l registros consecutivos con valor v. Por
ejemplo, la primera fila en la Fig. 13,3b indica que en la columna
EmployeeKey hay una serie de longitud cinco que comienza en la primera
posición y cuyo valor es e1. De manera análoga, el siguiente registro indica
5
que hay tres e2 en las posiciones 6–8.
13 nuevas tecnologías de
Aunque son eficientes para los escenarios anteriores, todavía quedan

muchos problemas por resolver con los sistemas de bases de datos de
almacenamiento de columnas, por ejemplo, proporcionarles capacidades
para soportar la actualización de una manera eficiente, un problema
resuelto en gran parte por los DBMS relacionales maduros (RDBMS).
a
RowId EmployeeKey CustomerKey ProductKey ···
1 e1 c1 p1 ···
2 e1 c1 p4 ···
3 e1 c2 p4 ···
4 e1 c2 p4 ···
5 e1 c2 p4 ···
6 e2 c2 p5 ···
7 e2 c2 p5 ···
8 e2 c2 p1 ···
9 e3 c3 p2
···
10 e3 c3 p2
···
··· ··· ··· ···
···
bcd
F v l F v l F v l
1 e1 5 1 c1 2 1 p1 1
6 e2 3 3 c2 6 2 p4 4
9 e3 2 9 c3 2 6 p5 2
... ... ... ... ... ... 8 p1 1
... ... ... ... ... ... 9 p2 2
... ... ... ... ... ... ... ... ...
Figura 13.3 Almacenar columnas de una tabla de hechos, una tabla por columna. (a)
Tabla de hechos Ventas. (b) Columna EmployeeKey. (c) Columna CustomerKey. (d)
Columna ProductKey
13.4 Sistemas de bases de datos en memoria
Un IMDBS es un DBMS que almacena datos en la memoria principal, a

diferencia de los sistemas de bases de datos tradicionales, que almacenan
datos en medios persistentes como discos duros. Debido a que trabajar con
datos en la memoria es mucho más rápido que escribir y leer desde un
sistema de archivos, los IMDBS pueden ejecutar aplicaciones en órdenes
de magnitud más rápido. Los IMDBS vienen en muchos sabores: pueden
ser DBMS que solo usan la memoria principal para cargar y ejecutar
análisis en tiempo real, pueden usarse como caché para DBMS basados en
disco, o pueden comercializarse como paquetes con licencia de software-
hardware, llamados dispositivos, en particular para aplicaciones de
inteligencia empresarial. En la mayoría de los casos, se combinan con
tecnología de almacenamiento en columna.
La forma típica en que operan los DBMS tradicionales se basa en la
lectura de datos del disco a las páginas del búfer ubicadas en la memoria
principal. Cuando se envía una consulta, los datos se recuperan primero en
estos búfer y, si no se encuentran, se cargan nuevos datos desde el disco a
la memoria principal. Si hay una actualización, la página modificada se
marca y se vuelve a escribir en el disco. El proceso en el que las bases de
datos basadas en disco mantienen los registros a los que se accede con
frecuencia en la memoria para un acceso más rápido es
13.4 Sistemas de bases de datos en memoria 517
llamado almacenamiento en caché. Sin embargo, tenga en cuenta que el

almacenamiento en caché solo acelera las lecturas de la base de datos,
mientras que las actualizaciones o escrituras aún deben escribirse a través
de la caché en el disco. Por lo tanto, el beneficio de rendimiento solo se
aplica a un subconjunto de tareas de la base de datos. Además, administrar
la caché es en sí mismo un proceso que requiere una cantidad considerable
de recursos de memoria y CPU. Un IMDBS reduce al mínimo estas
transferencias de datos, ya que los datos se encuentran principalmente en
la memoria. De ello se deduce que los objetivos de optimización de los
sistemas de bases de datos basados en disco se oponen a los de un IMDBS.
Los DBMS tradicionales intentan minimizar la entrada / salida (E / S)
usando el caché, consumiendo ciclos de CPU para mantener este caché.
Además, como hemos visto, mantienen datos redundantes, por ejemplo, en
estructuras de índices, para permitir el acceso directo a los registros sin
necesidad de bajar a los datos reales. De lo contrario,
Al igual que los DBMS tradicionales, los IMDBS típicos admiten las
propiedades de ACID, a saber, atomicidad, consistencia, aislamiento y
durabilidad. Los tres primeros son compatibles como en los DBMS
tradicionales. Dado que la memoria principal es volátil, la durabilidad está
respaldada por el registro de transacciones, en el que las instantáneas de la
base de datos se llaman periódicamente en ciertos instantes de tiempo
(llamados puntos de guardado o puntos de control, según la tecnología y el
proveedor) y se escriben en medios no volátiles. Si el sistema falla y debe
reiniciarse, la base de datos retrocede a la última transacción completada o
avanza para completar cualquier transacción que estaba en progreso
cuando el sistema falló. Los IMDBS también admiten la durabilidad al
mantener una o más copias de la base de datos, lo que, como en los
sistemas tradicionales, se denomina replicación.
Por último, el almacenamiento en disco se puede aplicar de forma
selectiva en un IMDBS. Por ejemplo, ciertos tipos de registros se pueden
escribir en el disco, mientras que otros se administran completamente en
la memoria. Las funciones específicas para bases de datos basadas en
disco, como la administración de caché, se aplican solo a los registros
almacenados en el disco, lo que minimiza el impacto de estas actividades
sobre el rendimiento y las demandas de la CPU.
Figura 13,4 describe la arquitectura de almacenamiento de datos típica
de un IMDBS.1 La base de datos se almacena en la memoria principal y se
compone de tres partes principales. La tienda principal contiene datos
almacenados de forma orientada a columnas. Por motivos de optimización
de consultas, algunos productos también almacenan juntos grupos de
columnas a las que normalmente se accede de forma conjunta. Se
denominan columnas combinadas. El almacenamiento intermedio es una
estructura de datos optimizada para escritura que contiene datos que aún
no se han movido al almacenamiento principal. Eso significa que una
consulta puede necesitar datos tanto de la tienda principal como del búfer.
La estructura de datos especial del búfer normalmente requiere más
espacio por registro que la tienda principal. Por lo tanto, los datos se
mueven periódicamente del búfer al almacén principal, un proceso que
requiere una operación de combinación. También hay estructuras de datos
que se utilizan para admitir características especiales. Los ejemplos son
índices invertidos
1
Esta figura está inspirada en la arquitectura SAP HANA (descrita más
adelante en el capítulo), aunque la mayoría de IMDBS siguen una
arquitectura similar.
Memoria principal
Datos activos
Tienda principal
Almacén de búfer Estructura adicional
Índices Guías de objetos Prejuntas

Unir
...
Columnas (simples y combinadas)

Algoritmos de envejecimiento de datos
Recuperación Inicio sesión
Datos históricos (pasivos)

Instantáneas de la base de datos
Registro de transacciones
Base de datos tradicional
Figura 13.4 Una arquitectura típica de IMDBS
para una rápida recuperación de datos de baja cardinalidad, como

columnas de clave primaria o guías de datos de objetos (en el caso de SAP),
que permiten reconstruir objetos de datos complejos almacenados como
una jerarquía de elementos. Por último, aunque los datos de la base de
datos se almacenan en la memoria principal, para ahorrar espacio en la
memoria, los IMDBS también almacenan datos de forma persistente. Esto
se hace de la siguiente manera. Los datos más recientes se guardan en la
memoria principal, ya que estos son los datos con mayor probabilidad de
ser accedidos y / o actualizados. Estos datos se denominan activos. Frente
a esto, los datos pasivos son datos que no se utilizan actualmente en un
proceso empresarial, que se utilizan principalmente con fines analíticos.
Los datos pasivos se almacenan en memoria no volátil, incluso utilizando
DBMS tradicionales. Esto admite las llamadas consultas de viaje en el
tiempo, que permiten conocer el estado de la base de datos en un momento
determinado. La partición de datos entre datos activos y pasivos se realiza
mediante algoritmos de antigüedad de datos. La memoria no volátil
también se utiliza para garantizar la coherencia y la recuperación en caso
de falla: las actualizaciones de datos se escriben en un archivo de registro y
las instantáneas de la base de datos se guardan en la memoria no volátil,
para ser leídas en caso de falla. Se supone que esta combinación de
memoria principal y no volátil permite que los IMDBS admitan
transacciones OLTP y análisis OLAP al mismo tiempo. Sin embargo, esta
capacidad está siendo cuestionada actualmente por investigadores y
13.5 Sistemas 5
profesionales. Se supone que esta combinación de memoria principal y no
volátil permite que los IMDBS admitan transacciones OLTP y análisis
OLAP al mismo tiempo. Sin embargo, esta capacidad está siendo
cuestionada actualmente por investigadores y profesionales. Se supone que
esta combinación de memoria principal y no volátil permite que los IMDBS
admitan transacciones OLTP y análisis OLAP al mismo tiempo. Sin
embargo, esta capacidad está siendo cuestionada actualmente por
investigadores y profesionales.
13.5 Sistemas representativos
Nosotros Comente ahora sobre algunos sistemas representativos que

utilizan tecnologías de bases de datos en memoria y almacenamiento de
columnas. Esto no pretende ser una lista exhaustiva y no expresa ninguna
preferencia de los autores sobre ningún proveedor en particular. Nuestro
objetivo es mostrar cómo la arquitectura general y las ideas presentadas
anteriormente se implementan en productos del mundo real. En esta
sección, primero presentamos tres ejemplos de sistemas de bases de datos
de almacenamiento de columnas, a saber, Vertica, MonetDB y MonetDB /
X100. Luego mostramos tres ejemplos de IMDBS, a saber, SAP HANA,
Oracle TimesTen y Oracle Exalytics. Concluimos con el enfoque de
Microsoft basado en índices de almacenamiento de columnas llamados
xVelocity.
13.5.1 Vertica
Vertica2 es un DBMS relacional distribuido masivamente paralelo, que se
basa en el proyecto de investigación C-Store realizado alrededor del año
2005. Aunque Vertica soporta las operaciones INSERT, UPDATE y
DELETE SQL, está diseñado principalmente para soportar cargas de
trabajo analíticas. Vertica tiene una arquitectura híbrida en memoria / en
disco. Ésta es la principal diferencia con nuestra arquitectura general en la
Fig.13,4, donde el almacenamiento principal y el almacenamiento
intermedio residen en la memoria y solo los datos pasivos se almacenan en
el disco. Vertica agrupa los datos en disco por columna en lugar de por fila,
con las ventajas ya comentadas para consultas analíticas. Además, los
datos se comprimen utilizando diferentes técnicas, no solo codificación de
longitud de ejecución.
Vertica organiza los datos en subconjuntos ordenados de los atributos de
una tabla. Estos se llaman proyecciones. Normalmente, hay una
proyección grande llamada superproyección (que contiene todas las
columnas de la tabla) y muchas proyecciones pequeñas. Tenga en cuenta
que esto puede considerarse análogo a las columnas combinadas en la
Fig.13,4. Vertica también admite proyecciones preunidas, aunque se ha
informado que en realidad no se utilizan con frecuencia. Vertica tiene dos
almacenes optimizados para lectura y escritura, que de alguna manera son
variantes de los almacenes principal y búfer de la Fig.13,4. El almacén
optimizado para escritura (WOS) es una estructura en memoria que está
optimizada para insertar, eliminar y actualizar datos. Los datos en el WOS
están descomprimidos, sin clasificar y segmentados y podrían almacenarse
en una forma orientada a filas o columnas. Esto permite una latencia baja
para un análisis de datos rápido en tiempo real. El almacén optimizado
para lectura (ROS) es un almacén basado en disco donde reside la mayoría
de los datos. Los datos en ROS se almacenan como conjuntos de pares
índice-valor, llamados contenedores ROS. Cada contenedor ROS se
compone de dos archivos por columna de la base de datos: uno que
contiene la columna en sí
13.5 Sistemas 5
http://www.vertica.com/
2
y el otro que contiene el índice de posición. En el ROS, se aplican

particiones y segmentaciones para facilitar el paralelismo. El primero,
también llamado partición intranodo, divide los datos horizontalmente, en
función de los valores de los datos, por ejemplo, por intervalos de fechas.
La segmentación (también llamada partición de entrenudos) divide los
datos entre los nodos de acuerdo con una clave hash. Cuando el WOS está
lleno, los datos se mueven al ROS mediante una función de salida. Para
ahorrar espacio en el ROS, se aplica una función de fusión (esto es análogo
a la operación de fusión en la Fig.13,4).
Finalmente, aunque se admiten inserciones, eliminaciones y
actualizaciones, Vertica puede no ser apropiado para aplicaciones de
actualización intensiva, como cargas de trabajo OLTP pesadas que, en
términos generales, exceden el 10% de la carga total.
13.5.2 MonetDB
MonetDB3 es un IMDBS de almacén de columnas desarrollado en
Centrum Wiskunde & Informatica (CWI)4 en los Paises Bajos. Las
principales características de MonetDB son un almacenamiento en
columnas; un álgebra de consulta masiva, que permite una rápida
implementación en hardware moderno; algoritmos conscientes de la
memoria caché; y nuevos modelos de costos, que dan cuenta del costo del
acceso a la memoria.
Por lo general, en el procesamiento de consultas RDBMS, al ejecutar un
plan de consulta, normalmente necesitamos escanear una relación R y
filtrarla usando una condición φ. El formato de R solo se conoce en el
momento de la consulta; por tanto, se necesita un intérprete de
expresiones. La idea de MonetDB se basa en el hecho de que la CPU se
utiliza básicamente para analizar la expresión de la consulta; por lo tanto,
los costos de procesamiento se pueden reducir optimizando el uso de la
CPU. Para simplificar la interpretación de consultas, el álgebra relacional
fue reemplazada por un álgebra más simple.
MonetDB también utiliza particiones verticales, donde cada columna de
la base de datos se almacena en la llamada tabla de asociación binaria
(BAT). Un BAT es una tabla de dos columnas en la que la columna de la
izquierda se denomina encabezado (en realidad, un identificador de objeto)
y la columna de la derecha, el final (el valor de la columna). El lenguaje de
consulta de MonetDB es un álgebra de columnas llamada MIL (Lenguaje
de interpretación de Monet). Los parámetros de los operadores tienen un
formato fijo: son tablas de dos columnas o constantes. La expresión
calculada por un operador también es fija, así como el formato del
resultado.
Sin embargo, el rendimiento no es óptimo ya que cada operación
consume MTD materializadas y produce una MTD materializada. Por lo
tanto, por un lado, dado que utiliza una técnica de evaluación de columna a
la vez, MIL no tiene el problema de gastar el 90% de su tiempo de
ejecución de consultas en una sobrecarga de interpretación de tupla a la
vez, como en RDBMS tradicionales, porque los cálculos funcionan en MTD
enteras, y el diseño de estas matrices se conoce en
13.5 Sistemas 5
http://www.monetdb.org/
3
http://www.cwi.nl/
4
tiempo de compilación. Por otro lado, las consultas que contienen cálculos
complejos sobre muchas tuplas materializan una columna de resultado
completa para cada función en la expresión, incluso cuando no se
requieren en el resultado de la consulta, sino solo como entrada para otras
funciones en la expresión. Si los resultados intermedios son pequeños, la
materialización no es realmente necesaria y produce una gran sobrecarga.
13.5.3 MonetDB / X100

A Resolver los inconvenientes de MonetDB, se diseñó un nuevo procesador
de consultas, llamado X100. Aquí, las columnas se fragmentan
verticalmente y se comprimen. Estos fragmentos se procesan de manera
eficiente utilizando una técnica llamada procesamiento vectorizado, que
opera sobre pequeños fragmentos verticales de elementos de datos en la
caché en lugar de registros individuales. X100 utiliza una variante del
álgebra relacional como lenguaje de consulta. Las operaciones relacionales
pueden procesar varias columnas al mismo tiempo. Las primitivas del
álgebra de MonetDB / X100 se parecen a las de un álgebra relacional
extendida: Scan, Select, Project, Join, Aggr (para agregación), TopN y
Order. Todos los operadores, excepto Order, TopN y Select, devuelven un
flujo de datos con el mismo formato que la entrada. Una consulta típica
escanea una columna a la vez, y luego la columna se pasa al árbol de
consultas,
UPC
Motor de ejecución X100
Árbol de consultas
Escanear
Cache Administrador de búfer de columna

Descompresión
Datos de columna
Memoria principal
Almacenamiento
Disco Disco Disco
Figura 13.5 Arquitectura MonetDB / X100
Figura 13,5 describe la arquitectura general de almacenamiento de datos

de MonetDB / X100. Todas las tablas se almacenan en forma fragmentada
verticalmente. Un almacenamiento
13.5 Sistemas 5
Se desarrolló un administrador llamado administrador de búfer de
columnas (ColumnBM). La principal diferencia con MonetDB es que el
primero almacena cada BAT en un solo archivo contiguo, mientras que
ColumnBM divide esos archivos en columnas (o fragmentos) y aplica
compresión para optimizar el uso de la memoria caché de la CPU. El
administrador de búfer gestiona la compresión y la descompresión. La
figura muestra también el fl ujo correspondiente a cada columna, desde el
disco hasta que es escaneada por el procesador de consultas y pasada al
árbol de consultas. Por lo tanto, en lugar de tuplas simples, vectores
completos de valores fluyen hacia arriba en el árbol. A esto se le llama
ejecución vectorizada. Como consecuencia, no es necesaria la
materialización de resultados intermedios como en MonetDB. Además,
toda la ejecución ocurre dentro de la caché de la CPU, ya que de aquí se
toman los vectores escaneados por el procesador de consultas. Como se
muestra en la Fig.13,5, la memoria principal solo se usa como un búfer de E
/ S administrado por ColumnBM. A esto se le llama procesamiento en
caché. Como ocurre con muchos sistemas, un problema con el
almacenamiento vertical es un mayor costo de actualización: una
actualización o eliminación de una sola fila debe realizar una E / S para
cada columna. MonetDB / X100 evita esto al considerar los fragmentos
verticales como objetos que no cambian. Para ello, se aplican
actualizaciones a los datos en las denominadas estructuras delta (es decir,
estructuras que almacenan nuevos datos). Una eliminación se maneja
agregando el identificador de tupla a una lista de eliminación y una
inserción como un anexo en columnas delta separadas. ColumnBM
almacena todas las columnas delta juntas. Por tanto, ambas operaciones
solo implican una operación de E / S. Las actualizaciones se tratan
simplemente como una eliminación seguida de una inserción. Cuando el
tamaño de la columna supera un umbral, se debe reorganizar el
almacenamiento de datos, que consiste en
haciendo que el almacenamiento vertical esté actualizado y las columnas
delta vacías.
13.5.4 SAP HANA

El enfoque de SAP para la inteligencia empresarial, conocido como
HANA,5 se basa en dos componentes principales:
1. La base de datos SAP HANA (también llamada SAP IMDBS), un IMDBS
híbrido que combina tecnologías basadas en filas, columnas y objetos,
optimizadas para aprovechar el procesamiento paralelo.
2. El dispositivo SAP HANA (SAP HANA), utilizado para analizar grandes
volúmenes de datos en tiempo real sin necesidad de materializar
agregaciones. Es una combinación de hardware y software entregado
por SAP en cooperación con socios de hardware, como IBM.
El núcleo de la base de datos de SAP HANA son dos motores de bases de
datos relacionales. El primero es un motor basado en columnas, que
contiene tablas con grandes cantidades de datos que se pueden agregar en
tiempo real y utilizar en operaciones analíticas. El segundo es un motor
basado en filas, optimizado para operaciones en filas, como
http://www.saphana.com
5
13.5 Sistemas 5
como inserciones y actualizaciones frecuentes. Este último tiene una tasa
de compresión más baja y un rendimiento de consulta más bajo en
comparación con el motor basado en columnas. Esta arquitectura permite
soportar cargas de trabajo mixtas en un mismo servidor, realizando
complejos cálculos analíticos sin necesidad de materializar tablas. Ambos
motores relacionales admiten SQL y MDX. Los cálculos se pueden realizar
en la base de datos sin mover los datos a la capa de la aplicación, a través
de un lenguaje de secuencia de comandos SQL que se puede utilizar para
introducir la lógica de la aplicación de datos intensivos en la base de datos.
El almacenamiento de filas o columnas se puede seleccionar en el
momento en que se crea una tabla, pero se puede cambiar posteriormente.
Ambos motores comparten una capa de persistencia común (el almacén de
datos no volátiles de la Fig.13,4), donde la gestión de páginas y el registro
son compatibles como en las bases de datos tradicionales.
La arquitectura de almacenamiento de datos es similar a la genérica que
se muestra en la Fig. 13,4, con un área de almacenamiento de columnas
optimizada y un área de búfer no optimizada para permitir inserciones y
actualizaciones. Las inserciones, eliminaciones y actualizaciones se
manejan en HANA siguiendo la noción de administración de por vida de
un dato.
registro. Un almacenamiento delta de nivel L1, organizado como un área de
almacenamiento orientada a filas, se utiliza para actualizaciones
individuales. Las actualizaciones masivas omiten el nivel L1 y se
administran en un almacenamiento delta de nivel L2, organizado en
columnas comprimidas, aunque está menos optimizado que el área de
almacenamiento principal. Finalmente, la tienda principal es la
almacenamiento de columna en memoria altamente comprimido explicado
anteriormente. Normalmente, los registros se mueven durante su ciclo de
vida desde el nivel L1 al nivel L2 y al almacén principal.
En cuanto al particionamiento, los datos se dividen en subconjuntos y se
almacenan en un clúster de servidores, conformando una base de datos
distribuida. Este enfoque se llama escalamiento horizontal. Una tabla de
base de datos individual se puede colocar en diferentes servidores dentro
de un clúster o se puede dividir en varias particiones, ya sea
horizontalmente (un grupo de filas por partición) o verticalmente (un
grupo de columnas por partición), con cada partición residiendo en un
servidor separado. dentro del clúster.
Atomicidad, la consistencia y el aislamiento son propiedades ACID que
no se ven afectadas por el almacenamiento en memoria. Sin embargo,
como se explicó anteriormente, la durabilidad no se puede lograr
simplemente almacenando datos en la memoria principal, ya que se trata
de un almacenamiento volátil. Para que los datos sean persistentes, deben
residir en un almacenamiento no volátil, como discos duros o dispositivos
flash. HANA divide la memoria principal en páginas. Cuando una
transacción cambia los datos, las páginas afectadas se marcan y escriben en
un almacenamiento no volátil a intervalos regulares. Además, un registro
de la base de datos captura todos los cambios realizados por las
transacciones. Cada transacción comprometida genera una entrada de
registro que se escribe en un almacenamiento no volátil, lo que garantiza
que todas las transacciones sean permanentes. SAP HANA almacena las
páginas cambiadas en los puntos de guardado, que se escriben de forma
asincrónica en el almacenamiento persistente a intervalos regulares (de
forma predeterminada, cada 5 minutos). Una transacción no se confirma
antes de que la entrada de registro correspondiente se escriba en el
almacenamiento persistente, para cumplir con el requisito de durabilidad
(en la administración de base de datos tradicional, esto se denomina
registro de escritura anticipada). Después de un corte de energía, la base de
datos se puede reiniciar desde los puntos de guardado como una base de
datos basada en disco: los registros de la base de datos se aplican para
restaurar los cambios.
13.5 Sistemas 5
que no se capturaron en los puntos de guardado, lo que garantiza que la
base de datos se pueda restaurar en la memoria al mismo estado que tenía
antes de la falla.
Finalmente, compresión se realiza utilizando diccionarios de datos. La
idea es que cada valor de atributo en una tabla se reemplace por un código
entero y la correspondencia de códigos y valores se almacene en un
diccionario. Por ejemplo, en la columna Ciudad de la tabla Cliente, el valor
Berlín se puede codificar como '1' y la tupla (Berlín, 1) se almacenará en el
diccionario. Así, si es necesario, se accederá una sola vez al valor
correspondiente (Berlín, en este caso). Por lo tanto, el movimiento de datos
se reduce sin imponer una carga de CPU adicional para la descompresión.
El factor de compresión logrado por este método depende en gran medida
de los datos que se comprimen. Los atributos con pocos valores distintos se
comprimen bien (por ejemplo, si tenemos muchos clientes de la misma
ciudad), mientras que los atributos con muchos valores distintos no se
benefician tanto.
13.5.5 Oráculo TimesTen

Oracle TimesTen6 es un RDBMS en memoria que también admite el
procesamiento de transacciones. TimesTen almacena todos sus datos en
estructuras de datos optimizadas en la memoria e incluye algoritmos de
consulta diseñados para el procesamiento en memoria.
TimesTen se puede usar como un RDBMS independiente o como un
caché de nivel de aplicación que funciona junto con el RDBMS tradicional
basado en disco, por ejemplo, la propia base de datos de Oracle: las
aplicaciones existentes en una base de datos de Oracle pueden usar
TimesTen para almacenar en caché un subconjunto de los datos para
mejorar el tiempo de respuesta. De esta manera, las operaciones de lectura
y escritura se pueden realizar en las tablas de caché usando SQL y PL /
SQL con persistencia automática, consistencia transaccional y
sincronización con la base de datos Oracle. Además, TimesTen se puede
utilizar para replicar un almacén de datos completo si cabe por completo
en la memoria.
A diferencia de los DBMS tradicionales, donde los optimizadores de
consultas se basan en los costos de entrada / salida del disco, es decir, el
número de accesos al disco, la función de costo del optimizador TimesTen
se basa en el costo de evaluar los predicados. La caché de TimesTen
proporciona índices de mapa de bits, hash y de rango, y admite algoritmos
de unión típicos como unión de bucle anidado y unión de combinación.
Además, el optimizador puede crear índices temporales según sea
necesario y acepta sugerencias del usuario, como en las bases de datos
tradicionales.
Dos características clave de la arquitectura de almacenamiento de datos
TimesTen son la caché de la base de datos en memoria y los algoritmos de
antigüedad de los datos. El caché de la base de datos en memoria (caché
IMDB) crea un caché actualizable en tiempo real donde se carga un
subconjunto de las tablas. Por ejemplo, en la base de datos Northwind, el
caché se puede utilizar para almacenar pedidos recientes, mientras que los
datos sobre los clientes se pueden almacenar en una base de datos
tradicional de Oracle. Así, la información que requiere acceso en tiempo
real se almacena en la caché de IMDB, mientras que la información
necesaria para
http://www.oracle.com/us/products/database/timesten/overview/index.html
6
13.5 Sistemas 5
El análisis, la auditoría y el archivo a más largo plazo se almacenan en la
base de datos de Oracle. Esto es análogo a la arquitectura general
representada en la Fig.13,4. Además, el escenario anterior se puede
distribuir. Por ejemplo, la empresa Northwind puede tener una base de
datos Oracle centralizada y muchas aplicaciones que se ejecutan en varios
nodos de servidores de aplicaciones en varios países. Para realizar análisis
de pedidos y ventas casi en tiempo real, podemos instalar una base de
datos de caché IMDB en cada nodo. Por el contrario, no es necesario
almacenar los perfiles de los clientes en todos los nodos. Cuando un nodo
aborda una orden de venta, el perfil del cliente se carga desde la ubicación
más actualizada, que podría ser un nodo o la base de datos central. Cuando
finaliza la transacción, el perfil del cliente se actualiza y se almacena de
nuevo en la base de datos central. La caché de IMDB también se puede
utilizar como caché de solo lectura, por ejemplo, para proporcionar un
acceso rápido a estructuras de datos auxiliares, como tablas de búsqueda.
Por otro lado, El envejecimiento de los datos es una operación que elimina
los datos que ya no son necesarios. Hay dos tipos generales de algoritmos
de antigüedad de datos: los que eliminan los datos antiguos en función de
un valor de marca de tiempo y los que eliminan los datos utilizados menos
recientemente. Como los otros sistemas comentados en este capítulo,
TimesTen usa la compresión de tablas a nivel de columna. Este mecanismo
proporciona reducción de espacio para las tablas al eliminar los valores
duplicados dentro de las columnas, mejorando el rendimiento de las
consultas SQL que deben realizar escaneos completos de la tabla.
Finalmente, TimesTen logra durabilidad de manera similar a SAP HANA,
es decir, mediante el registro de transacciones en una versión de la base de
datos basada en disco. TimesTen mantiene la versión basada en disco
usando una operación de punto de control que ocurre en segundo plano,
con bajo impacto en las aplicaciones de base de datos. TimesTen también
tiene un punto de control de bloqueo que no requiere archivos de registro
de transacciones para su recuperación y debe ser iniciado por la aplicación.
TimesTen utiliza el registro de transacciones para recuperar transacciones
con fallas, deshacer transacciones que se deshacen, replicar cambios en
otras bases de datos de TimesTen y / o
a las tablas de Oracle y permitir que las aplicaciones detecten cambios en las
tablas.
Además de lo anterior, Oracle también comercializa un dispositivo
llamado Oracle Exalytics In-Memory Machine, 7 similar al dispositivo SAP
HANA estudiado en la Sect. 13.5.4. Exalytics se compone de hardware,
software de inteligencia empresarial y Oracle TimesTen IMDBS. El
hardware consta de un único servidor configurado para análisis en
memoria de cargas de trabajo de inteligencia empresarial. Exalytics viene
con Oracle BI Foundation Suite y Essbase, un servidor OLAP
multidimensional mejorado con una sintaxis MDX más potente y un motor
de consultas MDX de alto rendimiento. Oracle Exalytics complementa
Oracle Exadata Database Machine, que admite un alto rendimiento para
aplicaciones OLAP y OLTP.
7
http://www.oracle.com/us/solutions/ent-performance-bi/business-intelligence/
exalytics-bi-machine / visión general / index.html
13.5 Sistemas 5
13.5.6 SQL Server xVelocity
El enfoque de Microsoft hacia la tecnología de almacenamiento en
columnas difiere de los descritos anteriormente. Microsoft decidió
mantener SQL Server como su único producto de base de datos e
incorporar la tecnología de almacenamiento de columnas en forma de
índice opcional. Microsoft SQL Server incluye una colección de tecnologías
de administración de datos en memoria y optimizadas para memoria
denominadas xVelocity.8 El motor de análisis en memoria xVelocity,
anteriormente conocido como VertiPaq, es un motor de almacenamiento
de columnas en memoria para consultas analíticas, que utiliza las cuatro
técnicas principales que discutimos anteriormente: almacenamiento en
columnas, técnicas de compresión, almacenamiento en caché en memoria
y alto paralelismo. escaneo de datos y
algoritmos de agregación. El motor xVelocity funciona con los modelos
tabulares de PowerPivot para Excel, SharePoint y Analysis Services, pero
no con las herramientas multidimensionales y de minería de datos de
Analysis Services.
El motor xVelocity proporciona índices de almacenamiento de columnas,
que apuntan a
mejorar el procesamiento de consultas en los almacenes de datos de SQL
Server. Cada columna se almacena por separado como en una base de
datos de almacenamiento de columnas. Además, xVelocity incluye una
tecnología de ejecución de consultas basada en vectores llamada
procesamiento por lotes para acelerar aún más el procesamiento de
consultas. Los datos se llevan a una memoria caché optimizada para la
memoria a pedido, aunque el rendimiento completo de las consultas en
memoria se logra cuando todos los datos necesarios para una consulta ya
están en la memoria principal. El índice de almacenamiento de columnas
de xVelocity agrupa y almacena datos para cada columna y luego une todas
las columnas para completar el índice completo. El procesador de
consultas de SQL Server puede aprovechar este tipo de índice para mejorar
significativamente el tiempo de ejecución de las consultas.
Una característica clave de los índices de almacenamiento de columnas
es que están integrados en SQL Server, que es un RDBMS de
almacenamiento de filas de propósito general, y los índices se pueden
definir como cualquier otro. Dada la ganancia de rendimiento que este
enfoque logra para muchos tipos de consultas de almacenamiento de datos,
incluso podemos deshacernos de la necesidad de crear y mantener tablas
de resumen. Sin embargo, estas características se combinan con algunas
limitaciones que discutiremos más adelante.
La sintaxis para crear un índice de almacén de columnas se introdujo en
el Cap. 7. Como ejemplo, indexamos las columnas de la tabla de hechos de
ventas en el almacén de datos de Northwind de la siguiente manera:
CREAR ÍNDICE DE COLUMNSTORE NO CLASIFICADO Ventas de CSIdx
EN Ventas (ProductKey, EmployeeKey, CustomerKey);
Los índices de almacén de columnas se organizan de la siguiente

manera. La tabla de hechos de ventas se almacena como grupos de filas.
Dado el índice de almacenamiento de columnas definido anteriormente,
para cada grupo de filas y cada columna, se construye un segmento que
contiene cada columna en un grupo en forma comprimida. Eso significa
que, en nuestro ejemplo, si la tabla contiene diez grupos, habrá treinta
segmentos de datos comprimidos. Cada segmento es
http://msdn.microsoft.com/en-us/library/hh922900.aspx
8
Mapa de bits de filas
13.5 Sistemas 5
Lote de filas
Vectores de columna
ProductKey
CustomerKey ...
Figura 13.6 Procesamiento de consultas por lotes de filas
almacenado en un BLOB (objeto binario grande). También hay un

directorio de segmentos que permite encontrar rápidamente todos los
segmentos de una columna determinada. Además, el directorio contiene
metadatos, como número de filas, valores mínimos y máximos, etc.
El elemento principal en el procesamiento por lotes es el lote de filas
(ver Fig. 13,6), un objeto que contiene alrededor de mil filas. Cada columna
del lote se representa internamente como un vector de elementos de
tamaño fijo. Hay un vector adicional denotado como vector de mapa de
bits de filas calificadas que se utiliza como sigue. Por ejemplo, para evaluar
una condición como ProductKey <1, necesitamos escanear la columna
ProductKey en el lote, realizar la comparación y, para cada elemento de
calificación, establecer el bit correspondiente en el vector de filas de
calificación. Los algoritmos eficientes basados en vectores reducen la
sobrecarga de la CPU de las operaciones de la base de datos. Se informa
que esta reducción puede ser de hasta cuarenta veces en comparación con
los métodos de procesamiento basados en filas.
Vale la pena señalar que los índices de almacén de columnas de SQL
Server y el procesamiento de consultas basado en columnas están
optimizados para consultas típicas en almacenes de datos con una tabla de
hechos grande y tablas de dimensiones pequeñas y medianas, siguiendo
una configuración de esquema en estrella. Dado que estas consultas
incluyen una combinación en estrella, predicados de selección sobre
atributos de dimensión y una agregación final, normalmente devuelven un
pequeño conjunto de resultados. Sin embargo, cuando el conjunto de
resultados es grande (p. Ej., Si los datos no se agregan o no hay una
combinación o filtrado), el rendimiento puede ser deficiente ya que no se
aplica el procesamiento por lotes y el beneficio del índice de
almacenamiento de columnas se debe solo a la compresión y el escaneo de
menos columnas. El rendimiento puede disminuir cuando (a) se unen dos
tablas grandes de modo que requieran tablas hash grandes que no caben en
la memoria y deben volcarse en el disco; (b) se devuelven muchas
columnas y, por lo tanto, se debe recuperar la mayor parte del índice de
almacenamiento de columnas; y (c) una condición de unión sobre una
tabla indexada de almacén de columnas incluye más de una columna.
En SQL Server, una tabla sobre la que se ha definido un índice de
almacén de columnas no se puede actualizar. Para superar este problema,
algunas técnicas ad hoc pueden
se aplicado. Por ejemplo, podemos eliminar el índice de almacén de

columnas; realizar las operaciones INSERT, DELETE o UPDATE
requeridas; y luego reconstruir el índice de almacenamiento de columnas.
Por supuesto, construir el índice en tablas grandes puede ser costoso, y si
este procedimiento debe seguirse con regularidad, puede que no sea
plausible. Como otra opción, podemos asignar datos identificados como
estáticos (o que rara vez cambian) en una tabla principal con un índice de
almacenamiento de columnas definido sobre ella. Los datos recientes, que
probablemente cambiarán, se pueden almacenar en una tabla separada con
el mismo esquema pero que no tiene definido un índice de
almacenamiento de columnas. Luego, podemos aplicar las actualizaciones.
Tenga en cuenta que esto requiere reescribir una consulta como dos
consultas, una para cada tabla, y luego combinar los dos conjuntos de
resultados con UNION ALL. La técnica de actualización anterior muestra
una de las ventajas de tener el almacenamiento de columnas como índice
en una base de datos orientada a filas: los procedimientos de actualización
ad hoc descritos se realizan automáticamente en la mayoría de los otros
productos que describimos en este capítulo. Por otro lado, esos productos
normalmente no son apropiados para cargas de trabajo transaccionales
pesadas.
13.6 Almacenes de datos en tiempo real
Muchas aplicaciones de almacenamiento de datos actuales deben manejar

grandes volúmenes de solicitudes simultáneas mientras mantienen un
tiempo de respuesta de consulta adecuado y deben escalar a medida que
aumenta el volumen de datos y la cantidad de usuarios. Esto es bastante
diferente de los primeros días del almacenamiento de datos, cuando solo
unos pocos usuarios accedían al almacenamiento de datos. Además, la
mayoría de estas aplicaciones deben permanecer disponibles
continuamente, sin una ventana de tiempo de actualización. Estas
aplicaciones requieren un nuevo enfoque para el proceso de extracción,
transformación y carga (ETL) estudiado en el Cap.8. Recuerde que los
procesos ETL extraen datos periódicamente de los sistemas de origen para
actualizar el almacén de datos. Este proceso es aceptable para muchas
aplicaciones de almacenamiento de datos del mundo real. Sin embargo, las
nuevas tecnologías de bases de datos estudiadas en este capítulo hacen
posible hoy en día lograr almacenes de datos en tiempo real, donde hay
alimentaciones continuas de almacenes de datos de los sistemas de
producción, y al mismo tiempo obtener resultados de análisis de datos
consistentes y confiables.
Como se estudia en este libro, el ciclo de vida de un registro de datos en
un entorno de inteligencia empresarial comienza con un evento
empresarial que tiene lugar. Los procesos ETL luego entregan el registro de
eventos al almacén de datos. Finalmente, el procesamiento analítico
convierte los datos en información para ayudar al proceso de toma de
decisiones, y una decisión comercial conduce a la acción correspondiente.
13.5 Sistemas 5
Para acercarse al tiempo real, el tiempo transcurrido entre el evento y su
acción consiguiente, llamado latencia de datos, debe minimizarse. Tomar
decisiones rápidas basadas en grandes volúmenes de datos requiere lograr
una baja latencia de datos, a veces a expensas de posibles inconsistencias
de datos (por ejemplo, datos atrasados o faltantes) y hardware
especializado. En el caso general, es el proceso de adquisición de datos el
que introduce la mayor parte de la latencia de datos.
13.6 Almacenes de datos en 5
Tenga en cuenta que los requisitos de latencia de datos difieren entre los
escenarios de aplicación. Por ejemplo, el filtrado colaborativo, con
consultas como "A las personas a las que les gusta X también les gusta Y",
requiere una actualización de datos en el rango de horas, mientras que la
detección de fraudes, por ejemplo, en el uso de tarjetas de crédito, necesita
una latencia de datos del orden de minutos o segundos. Sin embargo, la
mayoría de las aplicaciones no requieren estos estrictos niveles de latencia.
En estos casos, la estrategia común en la práctica consiste simplemente en
aumentar la frecuencia de las operaciones ETL utilizando los denominados
procesos ETL de mini lotes, por ejemplo, cargando datos cada 10 minutos.
Se han diseñado varias estrategias para lograr ETL en tiempo real para
reducir la latencia de los datos. El más simple, que requiere el menor
esfuerzo en términos de cambios en las arquitecturas existentes, es el
llamado ETL casi en tiempo real, que simplemente aumenta la frecuencia
de los procesos ETL. La mayor parte del trabajo de investigación en el
campo sigue este enfoque. Sin embargo, esto no es suficiente cuando la
latencia de los datos debe reducirse drásticamente.
Una solución clásica para reducir la latencia de datos consiste en definir
particiones en tiempo real para tablas de hechos. En este caso, los datos
estáticos y en tiempo real se almacenan en tablas independientes. Las
particiones en tiempo real están sujetas a reglas especiales de actualización
y consulta y deben tener el mismo esquema que las tablas de hechos.
Idealmente, deben:
• Contiene todas las actualizaciones ocurridas desde la última actualización
de la tabla de hechos.
• Tengo la misma granularidad que la tabla de hechos.
• Estar ligeramente indexado para manejar de manera eficiente los datos
de entrada.
• Admite consultas de alto rendimiento.
Las herramientas de consulta deben poder distinguir entre ambos tipos de
tablas y saber dónde encontrar datos. Eso significa que estas herramientas
deben formular una consulta sobre las tablas de hechos estáticos y las
particiones en tiempo real. Sin embargo, esta capacidad no siempre se
logra con herramientas comerciales. Tenga en cuenta también que esta
técnica es ortogonal a la tecnología de base de datos utilizada. Por lo tanto,
las particiones en tiempo real podrían almacenarse en RDBMS
tradicionales, sistemas de bases de datos de almacenamiento de columnas
o IMDBS.
Hay tres tipos de particiones en tiempo real según su granularidad, que
pueden ser transacciones, instantáneas periódicas y granularidad
acumulada de instantáneas. Explicamos estos tipos a continuación.
Una partición en tiempo real de granularidad de transacciones contiene
un registro para cada
transacción individual en el sistema fuente desde el comienzo de la
período de grabación. La partición en tiempo real tiene la misma
estructura que su tabla de hechos estática subyacente, pero solo contiene
las transacciones que se han producido desde la última actualización del
almacén de datos. Además, la partición en tiempo real no debe indexarse
para estar siempre lista para cargar. Aunque las tablas de hechos estáticos
suelen ser grandes y están muy indexadas, las particiones en tiempo real
pueden caber en la memoria principal y, por lo tanto, no es necesario
indexarlas. Como ejemplo, consideremos una versión simplificada de la
tabla de hechos de Ventas a continuación.
TimeKey EmployeeKey CustomerKey ProductKey Cantidad de

ventas
t1 e1 c1 p1 100
t2 e2 c2 p1 150
t3 e1 c3 p3 210
t4 e2 c4 p4 80
Suponga que esta tabla se actualiza una vez al día y que necesitamos
datos de hechos actuales. A continuación mostramos una partición en
tiempo real de granularidad de transacciones, llamada Partition Sales, que
almacena las transacciones que ocurrieron durante el último día, que no se
han cargado en la tabla de hechos.
TimeKey EmployeeKey CustomerKey ProductKey Cantidad de

ventas
t5 e1 c1 p1 30
t6 e2 c2 p1 125
t7 e3 c3 p3 300
Una consulta que solicite las ventas totales por empleado y cliente
necesitaría acceder a ambas tablas, de la siguiente manera:
SELECCIONE EmployeeKey, CustomerKey, SUM
(SalesAmount) DESDE (SELECCIONAR
EmployeeKey, CustomerKey,
SUM (SalesAmount) AS SalesAmount
FROMEmployee E, Customer C, Sales S
WHEREE.EmployeeKey = S.EmployeeKey
Y
C.CustomerKey =
S.CustomerKey GROUP BY EmployeeKey,
CustomerKey UNION
SELECCIONE EmployeeKey, CustomerKey,
SUM (SalesAmount) AS SalesAmount
FROMEmployee E, cliente C, ventas de
partición S WHEREE.EmployeeKey = S.EmployeeKey
Y
C.CustomerKey = S.CustomerKey
GROUP BY EmployeeKey, CustomerKey) AS
FactFull
GROUP BY FactFull.EmployeeKey, FactFull.CustomerKey
Una partición en tiempo real de instantánea periódica está relacionada

con una tabla de hechos con una granularidad más gruesa (por ejemplo,
semana). La partición en tiempo real contiene todas las trans-
acciones del período de instantánea actual (en este caso, la semana actual).
Los datos se agregan continuamente a esta partición y se resumen en la
granularidad de la tabla de hechos hasta que se completa el período,
manteniendo así un resumen continuo de los datos que aún no se han
cargado en la tabla de hechos estática. Suponga que en la tabla de hechos
de ventas simplificada anterior, la granularidad de tiempo es semana. A
medida que llegan nuevos pedidos, realizamos en la partición en tiempo
real un resumen continuo de la medida SalesAmount para la combinación
de empleado, cliente, producto y semana. Esto significa que el
La partición contiene datos resumidos hasta el momento actual de la
semana. Cuando cierra la semana, la partición se carga en la tabla de
hechos.
Finalmente, acumulando instantánea Las particiones en tiempo real se utilizan
para abreviar
procesos, como el manejo de pedidos. La partición en tiempo real acumula
frecuentes
actualizaciones de hechos, y la tabla de hechos se actualiza con la última
versión de estos hechos. Por ejemplo, suponga que en el estudio de caso de
Northwind, la tabla de hechos de ventas se actualiza una vez al día. Esta
tabla contiene registros sobre las líneas de pedido y sus datos (por ejemplo,
la fecha de vencimiento o la cantidad) pueden cambiar durante un día.
Estas actualizaciones se realizan en la partición en tiempo real, que
normalmente es pequeña y puede caber en la memoria principal. Al final
del día, los registros de la partición se cargan en la tabla de hechos.
Existen varios enfoques alternativos para lograr almacenes de datos en
tiempo real, que hacen uso de las particiones en tiempo real estudiadas
anteriormente. Uno de estos enfoques se llama alimentación por goteo
directo, donde los nuevos datos de fuentes operativas se introducen
continuamente en el almacén de datos. Esto se hace insertando datos en las
tablas de hechos o en particiones separadas en tiempo real de las tablas de
hechos. Una variante de esta estrategia, que aborda el problema de la carga
de trabajo mixta (es decir, actualizaciones y consultas sobre la misma
tabla), se llama goteo y fl ip. Aquí, los datos se introducen continuamente
en tablas de preparación que son una copia exacta de las tablas del
almacén. Periódicamente, la alimentación se detiene y la copia se
intercambia con la tabla de hechos, lo que actualiza el almacén de datos.
Otra estrategia llamada almacenamiento en caché de datos en tiempo real
evita problemas de cargas de trabajo mixtas: un caché de datos en tiempo
real consiste en un servidor de base de datos dedicado para cargar,
almacenar y procesar datos en tiempo real. Las tecnologías de bases de
datos en memoria estudiadas en este capítulo podrían usarse cuando
tenemos grandes volúmenes de datos en tiempo real (del orden de cientos
o miles de cambios por segundo) o requisitos de rendimiento de consultas
extremadamente rápidos. En este caso, los datos en tiempo real se cargan
en la caché a medida que llegan del sistema de origen. Un inconveniente de
esta estrategia es que, dado que los datos históricos y en tiempo real se
almacenan por separado, cuando una consulta involucra ambos tipos de
datos, la evaluación puede ser costosa. Las tecnologías de bases de datos en
memoria estudiadas en este capítulo podrían usarse cuando tenemos
grandes volúmenes de datos en tiempo real (del orden de cientos o miles de
cambios por segundo) o requisitos de rendimiento de consultas
datos, la evaluación puede ser costosa. Las tecnologías de bases de datos en
memoria estudiadas en este capítulo podrían usarse cuando tenemos
grandes volúmenes de datos en tiempo real (del orden de cientos o miles de
cambios por segundo) o requisitos de rendimiento de consultas
datos, la evaluación puede ser costosa.
Tenemos comenté anteriormente que no todas las aplicaciones tienen la
misma latencia
requisitos. En muchas situaciones, parte de los datos deben cargarse
rápidamente después de la llegada, mientras que otras partes se pueden
cargar a intervalos regulares. Sin embargo, hay muchas situaciones en las
que nos gustaría que los datos se carguen cuando sea necesario, pero no
necesariamente antes. El almacenamiento de datos en el momento
adecuado sigue este enfoque. Aquí, el tiempo correcto puede variar desde
ahora (es decir, tiempo real) hasta varios minutos u horas, según la latencia
de datos requerida. La idea clave es que los datos se carguen cuando se
necesiten, evitando el costo de proporcionar tiempo real cuando en
realidad no se necesitan.
El sistema RiTE (Right-Time ETL) es un middleware destinado a lograr
el almacenamiento de datos en el momento adecuado. En RiTE, un
productor de datos inserta continuamente datos en un almacén de datos de
forma masiva y, al mismo tiempo, las consultas de los usuarios del almacén
de datos obtienen acceso a datos nuevos bajo demanda. El principal
componente de la arquitectura RiTE se llama catalizador, un módulo de
software
que proporciona almacenamiento intermedio en la memoria principal para
las tablas del almacén de datos seleccionadas por el usuario. Más en
detalle, un consumidor de datos (de forma transparente para el usuario) le
dice al catalizador qué filas de una tabla deben estar listas
para realizar consultas, definir un período de tiempo (p. ej., "Necesito
todos los datos de hace como máximo 10 minutos"). Luego, el catalizador
solicita los datos al productor, y cuando se reciben los datos, se almacenan
en la memoria principal. Estos datos no comprometidos y no persistentes
quedan así disponibles para el consumidor, que accede a ellos a través de
funciones de tabla. Otros datos se cargan de forma masiva directamente en
el almacén de datos. Finalmente, los datos en el catalizador se
comprometen y se mueven a su objetivo final, las tablas del almacén de
datos físico. Tenga en cuenta que en este esquema, solo los datos
necesarios en tiempo real se consultan desde las tablas de memoria,
mientras que los datos con latencia más gruesa se pueden consultar
directamente desde el almacén de datos, y todo esto sucede de forma
transparente para el usuario.
Además del catalizador, hay dos módulos: el productor y el consumidor.
En el primero, y también en todos los consumidores, se ubican
controladores de bases de datos especializados. El controlador del
productor maneja las operaciones INSERT y COMMIT. El consumidor
utiliza un controlador de base de datos JDBC especializado que se registra
y cancela el registro con el catalizador, lo que indica qué filas de las tablas
de memoria se utilizan. Las filas se obtienen del catalizador mediante una
función de tabla de PostgreSQL (un procedimiento almacenado que
devuelve un conjunto de filas).
13.7 Extracción, carga y transformación
Están surgiendo nuevos paradigmas en el dominio del almacén de datos,

muchos de ellos sustentados en las posibilidades que ofrecen las
tecnologías estudiadas en este capítulo. Uno de ellos, denominado análisis
MAD, promueve un cambio en la
camino se está realizando un análisis de datos. Este paradigma reclama un
análisis magnético, ágil y profundo. El término magnético se refiere a la
capacidad de "atraer" fuentes de datos. En la metodología tradicional de
almacenamiento de datos estudiada en este
libro, las nuevas fuentes de datos no se incorporan al almacén de datos
hasta que se limpian e integran cuidadosamente. En cierto sentido, se dice
que este enfoque “repele” nuevas fuentes de datos. Esto puede no ser
apropiado, por ejemplo, cuando es necesario considerar fuentes de datos
externas y volátiles, por ejemplo, en un escenario de web semántica que
presentaremos en el Cap.14. En el enfoque MAD, se requiere que un
almacén de datos sea "magnético", es decir, debe
atraer todas las fuentes de datos independientemente de la calidad de los
mismos. El término ágil llama
para un almacén de datos que, en lugar de un diseño cuidadoso y detallado,
permite a los analistas cargar y producir datos rápida y fácilmente.
Finalmente, el término profundo se refiere al uso de técnicas modernas de
análisis de datos y métodos estadísticos.
que van más allá de las operaciones típicas de OLAP. Esto equivale a
incorporar técnicas como las estudiadas en el Cap.9, que también requiere
que se carguen grandes cantidades de datos en el almacén. Además de lo
anterior, hemos visto que muchas aplicaciones requieren tiempo real, casi
en tiempo real o en el tiempo correcto.
13.7 Extracción, carga y transformación 533
a
Fuentes de datos Base de datos provisional
Base de datos provisional
Almacén de datos
Extraer Transformar Carga
B
Fuentes de datos Base de datos provisional
Almacén de datosAlmacén de datos
ExtractLoadTransform
Figura 13.7 (a) Proceso de extracción, transformación y carga (ETL). (b) Proceso
de extracción, carga y transformación (ELT)
almacenamiento de datos. Además, la cantidad de datos operativos

producidos diariamente aumenta constantemente debido, entre otras
razones, a la globalización empresarial y la explosión del número de
transacciones en la web. En este escenario, es probable que el tiempo
necesario para actualizar el almacén de datos utilizando el proceso ETL
tradicional exceda la ventana de actualización asignada.
La discusión anterior tiene como objetivo explicar por qué algunos
profesionales y proveedores proponen un paradigma de carga de datos
diferente: el proceso de extracción, carga y transformación (ELT).
Hablamos de esto a continuación.
Considere la Fig. 13,7, que proporciona una vista detallada de la fase de
preparación de datos
en el nivel de back-end de la arquitectura representada en la Fig. 3,5. La
figura muestra que durante el proceso ETL, los datos se cargan desde las
fuentes a una base de datos provisional, donde ocurren las
transformaciones de datos necesarias, como se describe en el Cap.8.
Después de este proceso, los datos transformados se cargan en el almacén
de datos. El proceso garantiza que solo se extraerán y procesarán los datos
relevantes para la solución, lo que potencialmente reducirá la sobrecarga
de desarrollo, extracción y procesamiento. Esto también, en cierto sentido,
simplifica la gestión de la seguridad de los datos y, por lo tanto, los gastos
generales de administración de datos. Por otro lado, tener en cuenta solo
los datos relevantes implica que cualquier requisito futuro que pueda
necesitar datos no incluidos en el diseño original deberá agregarse a las
rutinas ETL. Esto puede conducir a importantes tareas de remodelación.
Además, el uso de herramientas de terceros para implementar procesos
ETL requiere el aprendizaje de nuevos lenguajes y procesos de scripting.
Por otro lado, los nuevos requisitos discutidos al comienzo de esta

sección llevaron al paradigma ELT, que se muestra en la Fig. 13,7B. Aquí,
los datos se extraen de las fuentes de datos a la base de datos provisional
utilizando cualquier herramienta de conectividad de datos disponible, no
solo middleware ETL especializado. En esta base de datos provisional, se
pueden aplicar verificaciones de integridad y reglas comerciales, y se
pueden realizar las correcciones pertinentes. Después de esto, los datos
fuente se cargan en el almacén, que proporciona una copia fuera de línea
validada de los datos fuente en el almacén de datos. Una vez en el almacén,
se realizan transformaciones para llevar los datos a su formato de salida de
destino. Podemos ver que mientras la transformación ETL ocurre en la
herramienta ETL, la transformación ELT ocurre en el
base de datos. De esta forma se pueden aislar los procesos de extracción y
carga
del proceso de transformación, permitiendo al usuario incluir datos que
pueden
será necesario en el futuro. Incluso la fuente de datos completa podría
cargarse en el almacén. Esto, combinado con el aislamiento del proceso de
transformación, significa que los requisitos futuros se pueden incorporar
fácilmente a la estructura del almacén, minimizando el riesgo de un
proyecto. Además, las herramientas proporcionadas con el motor de base
de datos se pueden utilizar para este proceso, lo que reduce la necesidad de
implementar y aprender herramientas ETL especializadas.
Nosotros Hay que tener en cuenta que ELT es un paradigma emergente
que, aunque prometedor, aún debe desarrollarse más. Este paradigma se
basa, en parte, en la carga de datos a alta velocidad, probablemente
utilizando grandes DBMS paralelos, por ejemplo, aprovechando
tecnologías como MapReduce, estudiada en la Sect.13,1.
13.8 Resumen
Tenemos estudió los cambios que los requisitos de análisis de big data están
introduciendo en el mundo del almacenamiento de datos y las respuestas
que la academia y la industria han ideado para ellos. Presentamos el
modelo MapReduce y su implementación más popular, Hadoop. También
presentamos dos lenguajes de consulta de alto nivel para Hadoop, a saber,
Pig Latin y HiveQL. También estudiamos dos arquitecturas de bases de
datos que están ganando impulso en el almacenamiento de datos y la
inteligencia empresarial: bases de datos de almacenamiento de columnas e
IMDBS. Describimos las principales características de algunos de los
sistemas de bases de datos basados en estas tecnologías: Vertica,
MonetDB, SAP HANA, Oracle TimesTen y Microsoft xVelocity. Por último,
analizamos dos paradigmas modernos que se utilizan cada vez más en el
almacenamiento de datos y la inteligencia empresarial: el almacenamiento
de datos en tiempo real y ELT.
13.10 Preguntas de repaso 535
Existe un amplio corpus de literatura académica y libros blancos

industriales sobre los temas cubiertos en este capítulo. En [193]. Los
autores de este libro exploran nuevos desafíos en el almacenamiento de
datos en [215], donde también se pueden encontrar muchas referencias. El
trabajo de Dean et al. [36] da una buena descripción de MapReduce.
Hadoop se describe, por ejemplo, en [226]. Hive se analiza en [25, 201] y
Pig Latin en [61]. En [195]. En [118]. C-Store, una de las primeras bases de
datos de almacenamiento de columnas, se analiza en [194]. Su versión
comercial Vertica está estudiada en [111]. MonetDB se revisa en [89]. Las
IMDBS se estudian en [164], donde también se analiza SAP HANA. Oracle
TimesTen se describe en [109]. Hay varios trabajos sobre almacenamiento
de datos en tiempo real y ETL en tiempo real [21,185,220]. Las particiones
en tiempo real se analizan en los libros [102,103]. La noción de
almacenamiento de datos en el momento oportuno se propone en [200]. El
enfoque ELT ha sido introducido en un artículo de Cohen et al. [33].
13.1 ¿Qué es Big Data? ¿Cómo caracterizar esta noción?

13.2 ¿Cuáles son los desafíos que plantean los macrodatos para el futuro
del almacenamiento de datos?
13.3 Describe las principales características del paradigma MapReduce.
13.4 Describe las principales características de Hadoop.
13.5 ¿Qué es Hive? ¿Qué es Pig Latin? Compare Hive y Pig Latin
proponiendo dimensiones para esta comparación.
13.6 Explique las principales características de las bases de datos de
almacenamiento de columnas.
13.7 ¿Cómo logran las bases de datos de almacenamiento en columnas
una mejor eficiencia que las bases de datos de almacenamiento en
filas en el caso de los almacenes de datos? ¿Es este el caso de las
bases de datos OLTP?
13.8 ¿Cómo comprimen los datos los sistemas de bases de datos de
almacenamiento de columnas?
13.9 ¿Qué son las IMDBS? ¿Qué tipos de ellos hemos estudiado en este
capítulo?
13.10 ¿Qué son los dispositivos de inteligencia empresarial?
13.11 ¿Cómo difieren las técnicas de optimización entre IMDBS y
sistemas de bases de datos basados en disco?
13.12 Describe una arquitectura IMDBS típica.
13.13 Describa las similitudes y diferencias entre SAP HANA, MonetDB y
Vertica.
13.14 ¿Cómo garantizan los IMDBS las propiedades ACID? Da una

respuesta para cada propiedad.
13.15 ¿Cuál es la principal diferencia entre el enfoque de xVelocity de SQL
Server y los sistemas anteriores?
13.16 ¿Qué son los almacenes de datos en tiempo real? Explique las
diferentes alternativas para modelar tablas de hechos en tiempo
real.
13.17 ¿Cómo podemos lograr ETL en tiempo real? ¿Siempre necesitamos
ETL en tiempo real? ¿Por qué? Explicar.
13.18 Explique el concepto de almacenes de datos en el momento
adecuado y en qué se diferencia de los almacenes de datos en
tiempo real. Explique un enfoque para lograr almacenes de datos en
el momento adecuado.
13.19 ¿En qué se diferencia ELT de ETL? Elija un escenario de aplicación
con el que esté familiarizado para motivar el uso de ELT.
13.11 Ejercicios
13.1 Tenga en cuenta que la base de datos Northwind se ha cargado en

HDFS. Queremos implementar las operaciones de álgebra relacional
sobre esta base de datos usando Pig Latin de la siguiente manera:
(a) Exprese la proyección sobre el apellido de la tabla Empleados.
(b) Exprese la selección de EmployeeID = 3 en la tabla Empleados.
(c) Sobre la tabla Pedidos, obtenga el número de entregas agrupadas
por remitente.
(d) Enumere la tabla Pedidos en orden descendente de ShipName.
(e) Realice la unión natural entre las tablas Pedidos y Empleado en
EmployeeID.
(f) Realice la unión externa izquierda entre las tablas Pedidos y
Empleado en PostalCode y ShipPostalCode en Pedidos.
(g) Igual que (e) para la combinación externa derecha, pero también
se une a EmployeeID.
13.2 Usando la base de datos Northwind de Ex. 13,1:
(a) Defina la base de datos en HiveQL.
(b) Expresar las consultas del Ex. 13,1 en HiveQL.
13.3 Considere la base de datos Northwind y la siguiente consulta:
SELECTCustomerName, SUM (SalesAmount)
FROMVentas S, Cliente C, Producto P, Hora T, Empleado
E WHERES.CustomerKey = C.CustomerKey Y
S.ProductKey = P.ProductKey Y
P.Discontinued = 'sí' Y
S.TimeKey = T.TimeKey Y T.Year = '2012' Y S.EmployeeKey =
E.EmployeeKey Y E.City = 'Berlina'
GRUPO POR C.Nombre del cliente
13.11 Ejercicios 537
Suponga que hay 100,000 tuplas en la tabla de hechos Ventas, 2,000

en Cliente, 30,000 en Producto, 500 en Tiempo y 1,000 en
Empleado. La base de datos Northwind se almacena en un sistema de
base de datos de almacenamiento de columnas. Cada bloque de disco
tiene un tamaño de 1 MB. Puedes asumir todos los datos que
consideres necesarios para dar respuesta a las siguientes preguntas:
• ¿Cuántos accesos a disco tomará la evaluación de la consulta
anterior?
• Suponga una base de datos orientada a filas, con un tamaño de
bloque de 32 K. ¿Cuál sería la respuesta a la pregunta anterior?
Capítulo 14
Almacenes de datos y web semántica
La disponibilidad de enormes cantidades de datos de muchos dominios

diferentes está produciendo un cambio en la forma en que se llevan a cabo
las prácticas de almacenamiento de datos. Las fuentes de datos a gran
escala se están volviendo comunes, lo que plantea nuevos desafíos para los
profesionales e investigadores del almacenamiento de datos. La web
semántica, donde se almacenan grandes cantidades de datos a diario, es un
escenario prometedor para el análisis de datos en un futuro próximo. A
medida que se disponga de grandes depósitos de datos anotados
semánticamente, aparecerán nuevas oportunidades para mejorar los
sistemas actuales de apoyo a la toma de decisiones. En este escenario, se
identifican claramente dos enfoques. Uno se centra en automatizar el
diseño multidimensional, utilizando artefactos web semánticos, por
ejemplo, ontologías existentes. En este enfoque, los almacenes de datos se
diseñan (semi) automáticamente utilizando metadatos disponibles y luego
se pueblan con datos de la web semántica. El otro enfoque tiene como
objetivo analizar grandes cantidades de datos web semánticos utilizando
herramientas OLAP. En este capítulo, abordamos el último enfoque, que
requiere la definición de un vocabulario preciso que permita representar
datos OLAP en la web semántica. Sobre este vocabulario se pueden de fi nir
modelos multidimensionales y operaciones OLAP para la web semántica.
Actualmente, hay dos propuestas en esta dirección. Por un lado, el
vocabulario del cubo de datos (también denominado QB) sigue modelos de
datos estadísticos. Por otro lado, el vocabulario QB4OLAP sigue de cerca
los modelos multidimensionales clásicos para OLAP estudiados en este
libro. lo que requiere la definición de un vocabulario preciso que permita
representar datos OLAP en la web semántica. Sobre este vocabulario se
pueden de fi nir modelos multidimensionales y operaciones OLAP para la
web semántica. Actualmente, hay dos propuestas en esta dirección. Por un
lado, el vocabulario del cubo de datos (también denominado QB) sigue
modelos de datos estadísticos. Por otro lado, el vocabulario QB4OLAP
sigue de cerca los modelos multidimensionales clásicos para OLAP
estudiados en este libro. lo que requiere la definición de un vocabulario
preciso que permita representar datos OLAP en la web semántica. Sobre
este vocabulario se pueden de fi nir modelos multidimensionales y
operaciones OLAP para la web semántica. Actualmente, hay dos
propuestas en esta dirección. Por un lado, el vocabulario del cubo de datos
(también denominado QB) sigue modelos de datos estadísticos. Por otro
lado, el vocabulario QB4OLAP sigue de cerca los modelos
multidimensionales clásicos para OLAP estudiados en este libro.
En este capítulo, primero lo introduciremos en la Secta. 14,1 la web
semántica básica
conceptos, incluidos los modelos de datos RDF y RDFS, junto con un
estudio de la representación RDF de datos relacionales y una revisión de
R2RML, el lenguaje estándar para definir asignaciones de datos
relacionales a RDF. En la secc.14,2, damos una introducción a SPARQL, el
lenguaje de consulta estándar para datos RDF. En la secc.14.3, discutimos
la representación y consulta de datos multidimensionales en RDF, incluida
una discusión en profundidad de los vocabularios QB y QB4OLAP.
Continuamos en la Secta.14,4 mostrando cómo se puede representar el
cubo de datos Northwind utilizando ambos vocabularios. Concluimos en la
Secta.14,5 por que muestra cómo consultar la representación QB4OLAP del
almacén de datos Northwind en SPARQL.
54655-6 14,
5 14 almacenes de datos y la web semántica
14.1 Web semántica
La web semántica es una propuesta orientada a representar contenido web

de forma procesable por máquina. La capa básica para la representación de
datos en la web semántica recomendada por el World Wide Web
Consortium (W3C) es el marco de descripción de recursos (RDF). En un
escenario de web semántica, las ontologías de dominio se utilizan para
definir una terminología común para los conceptos involucrados en un
dominio particular. Estas ontologías se expresan en RDF o en lenguajes
definidos sobre RDF como Web Ontology Language (OWL) 1 y son
especialmente útiles para describir datos no estructurados,
semiestructurados y de texto. Muchas aplicaciones adjuntan metadatos y
anotaciones semánticas a la información que producen (por ejemplo, en
aplicaciones médicas, imágenes médicas y pruebas de laboratorio).
Esperamos que, en un futuro próximo, estén disponibles grandes
repositorios de datos anotados semánticamente, lo que abre nuevas
oportunidades para mejorar los sistemas actuales de apoyo a la toma de
decisiones.
14.1.1 Introducción a RDF y RDFS

El marco de descripción de recursos (RDF)2 es un lenguaje formal para
describir información estructurada. Uno de los principales objetivos de
RDF es permitir la composición de datos distribuidos para permitir el
intercambio de datos a través de la web. Para identificar recursos de forma
única, RDF utiliza identificadores de recursos internacionalizados (IRI).
Los IRI generalizan el concepto de localizadores de recursos universales
(URL), ya que no necesariamente se refieren a recursos ubicados en la web.
Además, los IRI generalizan el concepto de identificadores uniformes de
recursos (URI): mientras que los URI se limitan a un subconjunto del
conjunto de caracteres ASCII, los IRI pueden contener caracteres Unicode.
RDF se puede utilizar para expresar afirmaciones sobre recursos. Estas
afirmaciones se expresan en forma de triples sujeto-predicado-objeto,
donde sujeto son recursos o nodos en blanco, predicado son recursos y
objeto son recursos o literales (es decir, valores de datos). Los nodos en
blanco se utilizan para representar recursos sin un IRI, normalmente con
una función estructural, por ejemplo, para agrupar un conjunto de
declaraciones. Un conjunto de triples RDF o conjunto de datos RDF puede
verse como un gráfico dirigido donde los sujetos y los objetos son nodos y
los predicados son arcos.
RDF proporciona una forma de expresar declaraciones sobre recursos
utilizando propiedades y valores con nombre. Sin embargo, a veces
también es necesario definir tipos o clases de recursos y las propiedades
específicas que describen esos recursos. Un conjunto de palabras
reservadas, llamado RDF Schema (RDFS),3 se utiliza para de fi nir
1
http://www.w3.org/2004/OWL/
2
http://www.w3.org/TR/rdf11-concepts/
3
http://www.w3.org/TR/rdf-schema/
14.1 Web 5
propiedades y representan relaciones entre recursos, agregando semántica
a los términos en un vocabulario. De manera intuitiva, RDF nos permite
describir instancias, mientras que RDFS agrega información de esquema a
esas instancias. Un estudio completo de la semántica formal de RDFS está
más allá del alcance del libro, pero proporcionamos a continuación los
conceptos básicos que usaremos en las siguientes secciones.
Entre los muchos términos del vocabulario RDFS, el fragmento que
representa las características esenciales de RDF es el subconjunto
compuesto por los siguientes términos: rdf: type, rdf: Class, rdfs: Resource,
rdfs: Property, rdfs: range, rdfs: domain , rdfs: subClassOf y rdfs:
subPropertyOf. Por ejemplo, una clase triple Employee rdf: type indica que
Employee es una clase que agrega objetos del mismo tipo, en este caso
empleados (dejamos los problemas sintácticos para presentarlos más
adelante, ya que en realidad todos los recursos deben definirse mediante
IRI). El triple Davolio rdf: type Employee dice que Davolio es miembro de
la clase Employee. El término rdfs: Resource denota la clase de todos los
recursos y rdf: Property la clase de todas las propiedades. Es importante
destacar que la pertenencia a una clase no es exclusiva, ya que un recurso
puede pertenecer a varias clases diferentes. Elementos pertenecientes a la
clase rdf: La propiedad representa las relaciones entre los recursos, que se
utilizan en la parte de predicado de los triples RDF. Por ejemplo, hasSalary
puede definirse como una propiedad de un empleado usando la instrucción
hasSalary rdf: type rdf: Property. El predicado rdfs: subClassOf nos
permite definir relaciones de generalización entre clases. Por ejemplo, el
rdf triple TemporaryEmployee: subClassOf Employee dice que cada
empleado temporal también es un empleado. De manera análoga, el
predicado rdfs: subPropertyOf nos permite definir relaciones de
generalización entre propiedades. Por ejemplo, hasLowSalary rdfs:
subPropertyof hasSalary indica una subpropiedad para describir a los
empleados con salarios bajos. Un sistema de reglas se puede definir
utilizando estos y otros predicados, lo que permite inferir conocimientos a
partir de un gráfico RDF. La semántica RDF utilizado en la parte de
predicado de los triples RDF. Por ejemplo, hasSalary puede definirse como
una propiedad de un empleado usando la instrucción hasSalary rdf: type
rdf: Property. El predicado rdfs: subClassOf nos permite definir relaciones
de generalización entre clases. Por ejemplo, el rdf triple
TemporaryEmployee: subClassOf Employee dice que cada empleado
temporal también es un empleado. De manera análoga, el predicado rdfs:
subPropertyOf nos permite definir relaciones de generalización entre
propiedades. Por ejemplo, hasLowSalary rdfs: subPropertyof hasSalary
indica una subpropiedad para describir a los empleados con salarios bajos.
Un sistema de reglas se puede definir utilizando estos y otros predicados,
lo que permite inferir conocimientos a partir de un gráfico RDF. La
semántica RDF utilizado en la parte de predicado de los triples RDF. Por
ejemplo, hasSalary puede definirse como una propiedad de un empleado
usando la instrucción hasSalary rdf: type rdf: Property. El predicado rdfs:
subClassOf nos permite definir relaciones de generalización entre clases.
Por ejemplo, el rdf triple TemporaryEmployee: subClassOf Employee dice
que cada empleado temporal también es un empleado. De manera análoga,
el predicado rdfs: subPropertyOf nos permite definir relaciones de
partir de un gráfico RDF. La semántica RDF hasSalary se puede definir
como una propiedad de un empleado usando la instrucción hasSalary rdf:
type rdf: Property. El predicado rdfs: subClassOf nos permite definir
relaciones de generalización entre clases. Por ejemplo, el rdf triple
TemporaryEmployee: subClassOf Employee dice que cada empleado
temporal también es un empleado. De manera análoga, el predicado rdfs:
subPropertyOf nos permite definir relaciones de generalización entre
propiedades. Por ejemplo, hasLowSalary rdfs: subPropertyof hasSalary
indica una subpropiedad para describir a los empleados con salarios bajos.
Un sistema de reglas se puede definir utilizando estos y otros predicados,
lo que permite inferir conocimientos a partir de un gráfico RDF. La
semántica RDF hasSalary se puede definir como una propiedad de un
empleado usando la instrucción hasSalary rdf: type rdf: Property. El
predicado rdfs: subClassOf nos permite definir relaciones de
generalización entre clases. Por ejemplo, el rdf triple TemporaryEmployee:
subClassOf Employee dice que cada empleado temporal también es un
empleado. De manera análoga, el predicado rdfs: subPropertyOf nos
permite definir relaciones de generalización entre propiedades. Por
ejemplo, hasLowSalary rdfs: subPropertyof hasSalary indica una
subpropiedad para describir a los empleados con salarios bajos. Un sistema
de reglas se puede definir utilizando estos y otros predicados, lo que
permite inferir conocimientos a partir de un gráfico RDF. La semántica
RDF el triple TemporaryEmployee rdf: subClassOf Employee dice que cada
empleado temporal también es un empleado. De manera análoga, el
predicado rdfs: subPropertyOf nos permite definir relaciones de
partir de un gráfico RDF. La semántica RDF el triple TemporaryEmployee
rdf: subClassOf Employee dice que cada empleado temporal también es un
empleado. De manera análoga, el predicado rdfs: subPropertyOf nos
permite definir relaciones de generalización entre propiedades. Por
ejemplo, hasLowSalary rdfs: subPropertyof hasSalary indica una
subpropiedad para describir a los empleados con salarios bajos. Un sistema
de reglas se puede definir utilizando estos y otros predicados, lo que
permite inferir conocimientos a partir de un gráfico RDF. La semántica
RDF permitiendo así inferir conocimientos a partir de un gráfico RDF. La
semántica RDF permitiendo así inferir conocimientos a partir de un gráfico
RDF. La semántica RDF4 La especificación define una semántica precisa y
los correspondientes sistemas completos de reglas de inferencia para RDF
y RDFS. Finalmente, observemos que, en general, las triples que
representan el esquema y los datos de instancia coexisten en conjuntos de
datos RDF.
14.1.2 Serializaciones RDF

Un gráfico RDF es una colección de triples dados en cualquier orden, lo
que sugiere muchas formas de serialización. Dos notaciones ampliamente
14.1 Web 5
utilizadas son RDF / XML,5 que de fi ne una sintaxis XML para RDF y
Turtle,6 que proporciona una forma sencilla de representar triples RDF.
4
http://www.w3.org/TR/rdf11-mt/
5
http://www.w3.org/TR/rdf-syntax-grammar/
6
http://www.w3.org/TR/turtle/
http://example.org/NWDW#hasEmployee
1992-05-01 Nancy Davolio
Figura 14.1 Un ejemplo de un gráfico RDF
Figura 14,1 representa un gráfico RDF que representa a un empleado de

la empresa Northwind, su primer nombre, apellido y fecha de contratación.
El siguiente fragmento de código RDF / XML describe este gráfico.
<versión xml ''1.0'' codificación = ''utf8''?>
<rdf: RDF
xmlns: rdf =''http://www.w3.org/1999/02/22-rdf-syntax-ns#''
xmlns: ex =''http://example.org/NWDW#''>
<rdf: Descripción rdf: about =''http://example.org/NWDW#iri''>
<ex: hasEmployee>
<rdf: Descripción rdf: about =''http://example.org/NWDW#employee1''>
<ex: FirstName>Nancy</ ex: Nombre>
<ej .: Apellido>Davolio</ ex: Apellido>
<ex: HireDate>1992-05-01</ ex: HireDate>
</ rdf: Descripción>
</ ex: hasEmployee>
</ rdf: Descripción>
</ rdf: RDF>
La primera línea es la típica línea de encabezado XML y el documento

comienza con el elemento RDF. El atributo xmlns se utiliza para definir
espacios de nombres XML compuestos por un prefijo y un IRI, lo que hace
que el texto sea menos detallado. El sujeto y objeto del triple que
representa a la empresa y su empleado se encuentran dentro de los
elementos Descripción, donde el atributo rdf: about indica los IRI de los
recursos. El prefijo ex se refiere al almacén de datos de Northwind.
El mismo triple se escribirá de la siguiente manera usando Turtle:
@pre fi x rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@pre fi x ex:<http://example.org/NWDW#> .
ex: iri ex: hasEmployee ex: employee1.

ex: employee1 rdf: type ex: Employee; ex: FirstName''Nancy''
; ej .: Apellido''Davolio'' ; ex: HireDate''1992-05-01'' .
Tenga en cuenta que Turtle proporciona una sintaxis mucho más simple y
menos detallada, en comparación con RDF / XML, por lo que usamos
Turtle en el resto del capítulo.
Los tipos de datos se admiten en RDF a través del sistema de tipos de
datos XML. Por ejemplo, de forma predeterminada, ex: HireDate se
interpretaría como un valor de cadena en lugar de un valor de fecha. Para
definir explícitamente los tipos de datos para el ejemplo anterior,
escribiríamos en Turtle:
14.1 Web 5
@pre fi x ex:<http://example.org/NWDW#> .
@pre fi x xsd: <http://www.w3.org/2001/XMLSchema#> .
ex: iri ex: hasEmployee ex: employee1.
ex:mimetroployee1 rdf: tipo ex:MImetroployee ; ex: FirstNametromi
''Nancy''∧∧xsd: cadena ; ej .: Apellido ''Davolio''∧∧xsd: cadena; ex:
HireDate''1992-05-01''∧∧xsd: fecha .
A Para simplificar aún más la notación, Turtle permite que rdf: type sea
reemplazado por 'a'. Por lo tanto, en lugar de
ex: employee1 rdf: type ex: Employee;
podríamos escribir
ex: employee1 a ex: Employee;
Además, el atributo xml: lang nos permite indicar el idioma del texto en
el triple. Por ejemplo, para indicar que el nombre del empleado es un
nombre en inglés, podemos escribir en Turtle:
ej .: empleado1 ej .: Nombre ''Nancy''@en; ej .: Apellido''Davolio''@en.
Finalmente, los nodos en blanco se representan explícitamente con un

identificador de nodo en blanco de la forma: nombre o sin nombre usando
corchetes. Este último se utiliza si el identificador no se necesita en
ninguna otra parte del documento. Por ejemplo, los siguientes triples
indican que el empleado identificado por ex: employee1, que corresponde a
Nancy Davolio en los triples anteriores, tiene un supervisor que es un
empleado llamado Andrew Fuller:
ex: employee1 a ex: Employee;
ex: Supervisor [ex: Empleado; ex: FirstName''Andrés'' ; ej .: Apellido''Batán'' ].
En este caso, el nodo en blanco se utiliza como objeto y este objeto es un

recurso anónimo; no nos interesa quién es esta persona.
Un nodo en blanco se puede utilizar como sujeto en triples. Si
necesitamos usar el nodo en blanco en otra parte del documento, podemos
usar la siguiente notación de tortuga:
ex: employee1 a ex: Employee; ex: Supervisor: empleado2.
: employee2 a ex: Employee; ex: FirstName''Andrés''; ej .: Apellido''Batán'' .
14.1.3 Representación RDF de datos relacionales

En esta sección, describimos cómo se pueden representar los datos
relacionales en RDF para ser utilizados y compartidos en la web semántica.
Supongamos que la empresa Northwind desea compartir sus datos de
almacén en la web, por ejemplo, para que todas sus sucursales puedan
acceder a ellos. El almacén de datos de Northwind se almacena en una base
de datos relacional. Para nuestro ejemplo, utilizaremos la tabla de hechos
de ventas y la tabla de dimensiones del producto de la Fig.14,2, que son
versiones simplificadas de las tablas del almacén de datos
correspondientes. Tenga en cuenta que agregamos un identificador
SalesKey para cada tupla en la tabla de hechos de ventas.
a
SalesKey ProductKey CustomerKey TimeKey Cantida
d
s1 p1 c1 t1 100
s2 p1 c2 t2 100
··· · ·· ··· ··· ···
B
ProductKey Nombre del Cantidad por Precio Interrumpido Nombre de la
producto unidad unitario categoría
p1 prod1 25 60 No c1
p2 prod2 45 60 No c1
··· ··· · ·· ··· · ·· ···
Figura 14.2 Un extracto de una versión simplificada del almacén de datos de

Northwind.
(a) Tabla de hechos de ventas. (b) Tabla de dimensiones del producto
El World Wide Web Consortium (W3C) ha propuesto dos formas de

mapear datos relacionales a RDF: el mapeo directo y el mapeo R2RML,
que presentamos a continuación.
Mapeo directo
El mapeo directo7 de fi ne una representación gráfica RDF de los datos en

una base de datos relacional. Este mapeo toma como entrada el esquema y
la instancia de un
base de datos relacional y produce un gráfico RDF llamado gráfico directo,
cuyos triples se forman concatenando los nombres y valores de las
columnas con un IRI base.
En los ejemplos siguientes, el IRI base es <http://example.org/>. La
asignación también tiene en cuenta las claves externas en las bases de
datos que se asignan. El mapeo directo para la tabla de hechos de ventas y
la tabla de dimensiones del producto en la Fig.14,2 da como resultado un
gráfico RDF, del cual mostramos a continuación algunos triples:
@base <http://example.org/>
@pre fi x rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#>
<Sales / SalesKey =''s1''> rdf: tipo <Ventas> .

<Sales / SalesKey =''s1''> <Ventas # SalesKey> ''s1'' .
<Sales / SalesKey =''s1''> <Ventas # ProductKey> ''p1'' .
<Sales / SalesKey =''s1''> <Ventas # ref-ProductKey> <Product / ProductKey =''p1''> .
<Sales / SalesKey =''s1''> <Ventas # CustomerKey> ''c1'' .
<Sales / SalesKey =''s1''> <Ventas # ref-CustomerKey>
<Customer / CustomerKey =''c1''> .
<Sales / SalesKey =''s1''> <Ventas # TimeKey> ''t1'' .
<Sales / SalesKey =''s1''> <Ventas # ref-TimeKey> <Time / TimeKey =''t1''> .
<Sales / SalesKey =''s1''> <Cantidad de ventas> ''100'' .
...
http://www.w3.org/TR/rdb-direct-mapping/
7
14.1 Web 5
<Product / ProductKey =''p1''> rdf: tipo <Producto> .
<Product / ProductKey =''p1''> <Producto # ProductKey> ''p1'' .
<Product / ProductKey =''p1''> <Ventas # ProductName> ''prod1'' .
<Product / ProductKey =''p1''> <Ventas # CantidadPerUnidad> ''25'' .
<Product / ProductKey =''p1''> <Ventas # UnitPrice> ''60'' .
<Product / ProductKey =''p1''> <Ventas # descontinuado> ''No'' .
<Product / ProductKey =''p1''> <Ventas # CategoryKey> ''c1'' .
<Product / ProductKey =''p1''> <Ventas # ref-CategoryKey>
<Category / CategoryKey =''c1''> .
...
Cada fila de Ventas produce un conjunto de triples con un tema común.

El asunto es un IRI formado a partir de la concatenación del IRI base, el
nombre de la tabla, el nombre de la columna de la clave principal
(SalesKey) y el valor de la clave principal (s1 para la primera tupla). El
predicado para cada columna es un IRI formado como la concatenación del
IRI base, el nombre de la tabla y el nombre de la columna. Los valores son
literales RDF tomados de los valores de columna. Cada clave externa
produce un triple con un predicado compuesto por los nombres de
columna de clave externa, la tabla referenciada y los nombres de columna
referenciada. El objeto de estos triples es el identificador de fila del triple
referenciado. Los identificadores de la fila de referencia deben coincidir
con el tema utilizado para los triples generados a partir de la fila de
referencia. Por ejemplo, el triple
<Sales / SalesKey =''s1''> <Ventas # ref-ProductKey> <Product / ProductKey
=''p1''>
dice que el sujeto (la primera fila en Ventas) contiene una clave externa en
la columna ProductKey (el predicado en el triple) que se refiere al triple
identificado en el objeto (el triple cuyo sujeto es <Product / ProductKey = ''
p1 ''>). Como puede verse, el mapeo directo es muy sencillo, aunque rígido,
en el sentido de que no permite ningún tipo de personalización. De hecho,
la estructura del gráfico RDF resultante refleja directamente la estructura
de la base de datos, el vocabulario RDF de destino refleja directamente los
nombres de los elementos del esquema de la base de datos, y ni la
estructura ni el vocabulario pueden
ser cambiado.
Mapeo R2RML
R2RML8 es un lenguaje para expresar asignaciones de bases de datos

relacionales a conjuntos de datos RDF. Dichas asignaciones brindan la
capacidad de ver datos relacionales en RDF utilizando una estructura y
vocabulario personalizados. Al igual que con el mapeo directo, un mapeo
R2RML da como resultado un gráfico RDF.
Un mapeo R2RML es un gráfico RDF escrito en sintaxis Turtle, llamado
documento de mapeo. El objeto principal de un mapeo R2RML es el
llamado mapa de triples. Cada mapa de triples es una colección de triples,
compuesto por un
http://www.w3.org/TR/r2rml
8
lógico mesa, un mapa de sujetos y cero o más mapas de objetos predicados.

Una tabla lógica es una tabla base o una vista (usando el predicado rr:
tableName) o una consulta SQL (usando el predicado rr: sqlQuery). Un
mapa de objeto predicado es
compuesto por un mapa de predicados y un mapa de objetos. Los mapas de
sujetos, los mapas de predicados y los mapas de objetos son constantes (rr:
constante), mapas basados en columnas (rr: columna) o mapas basados en
plantillas (rr: plantilla). Las plantillas utilizan nombres de columna entre
llaves como marcadores de posición. Como ejemplo, la Fig.14.3 muestra
cómo una parte de la tabla de dimensiones Producto se asigna a RDF
mediante R2RML. Este mapeo se puede aplicar luego a cualquier instancia
de la tabla para producir los triples. A continuación, mostramos el
documento de mapeo, que, junto con la instancia de la tabla, producirá el
gráfico RDF:
#TriplesMap_Product
rr: logicTable rr: subjectMap rr: predicateObjectMap
rr: tableNamerr: templaterr: class rr: predicado rr: predicado

rr: objectMaprr: objectMap
Producto ../{ProductKey} ex: productex: productName ex: unitPrice
rr: columna rr: columna
Figura 14.3 Mapeo R2RML de la dimensión ProductoNombre del Precio
@pre fi x rr: <http://www.w3.org/ns/r2rml#> .

@pre fi x rdfs:<http://www.w3.org/2000/01/rdf-schema#> .
@pre fi x ex:<http://example.org/> .
<Producto
#TriplesMap> a rr:
TriplesMap;
rr: tablaLógica [rr: nombreTabla ''Producto'' ]; rr:
subjectMap [
rr: plantilla ''http://example.org/product/ ProductKey '' ;
{ }
rr: clase ex: producto];
rr: predicateObjectMap [rr:
predicado ex: productName;
rr: objectMap [rr: columna ''Nombre del producto'' ; rr: idioma''en'' ]; ]; rr:
predicateObjectMap [
rr: predicado ex: unitPrice;
rr: objectMap [rr: columna ''Precio unitario'' ; rr: tipo de datos rdfs: integer]; ].
El mapa de triples de arriba (correspondiente a la tabla Producto) se llama

<Producto #TriplesMap>. La tabla lógica es la tabla Producto, y el
14.2 5
asunto es la plantilla de la clave ProductKey. Aplicado a la tabla de entrada,
esto producirá el sujeto de los triples. Para cada uno de estos sujetos, el
mapeo predicado-objeto producirá el mapeo de las columnas que
deseamos mapear. Por ejemplo, rr: predicate ex: productName asignará la
columna ProductName. Tenga en cuenta que este procedimiento nos
permite personalizar el nombre de la columna, por ejemplo, de acuerdo
con un vocabulario determinado. A continuación, mostramos algunos de
los triples producidos por este mapeo cuando se aplica a la tabla Producto
en la Fig.14,2B:
<http://example.org/product/p1>
a <http://example.org/product> ;
<http://example.org/productName> ''prod1''@en;
<http: // exametrople.org/unitPrice> ''60''∧∧
<http://www.w3.org/2000/01/rdf-schema#integer>
... ;
Extranjero las claves se manejan a través de mapas de objetos de

referencia, que utilizan los sujetos de otro mapa de triples como los objetos
generados por un objeto predicado
mapa:
<#TriplesMap Ventas> rr:
predicateObjectMap [
rr: predicado ex: producto; rr:
objectMap [
rr: parentTriplesMap <Producto #TriplesMap> ; rr:
joinCondition [
rr: niño ''ProductKey'' ;
rr: padre ''ProductKey'' ]; ]; ].
El predicado rr: parentTriplesMap hace referencia a un mapa triple

existente en el mismo archivo de mapeo que genera el recurso deseado. En
el ejemplo anterior, en el archivo de mapeo para la tabla de hechos de
Ventas, al mapear la clave externa para la tabla Producto, hacemos
referencia al mapeo para este último (que hemos llamado <#TriplesMap
Product>). La condición de unión (rr: joinCondition) contiene dos
elementos, a saber, rr: child y rr: parent. El primero está asociado con un
nombre de columna de la tabla lógica del mapa de triples que contiene el
mapa del objeto de referencia. Este último está asociado con un nombre de
columna lógica del mapa de triples referenciado.
14.2 SPARQL
SPARQL9 es el lenguaje de consulta estándar para gráficos RDF. Las

consultas SPARQL se crean utilizando variables, que se indican mediante
'?' o '$' como prefijo, aunque normalmente se usa el primero. El
mecanismo de evaluación de consultas de
http://www.w3.org/TR/sparql11-query/
9
SPARQL se basa en la coincidencia de subgrafos, donde los criterios de

selección se expresan como un patrón de gráfico. Este patrón se compara
con un gráfico RDF que instancia las variables en la consulta.
En lo que sigue, trabajaremos con el almacén de datos de Northwind
representado como un gráfico RDF, como se estudia en la Sect. 14.1.3.
Analicemos la siguiente consulta SPARQL, que solicita nombres y fecha de
contratación de los empleados:
PREFIJO ex:<http://example.org/NWDW#>
PREFIJO rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#>
SELECT? FirstName? LastName?

HireDate WHERE? Emp a ex: Employee
{
.
? emp ex: Empleado # Nombre? primer Nombre.
? emp ex: Empleado # Apellido? Apellido.
? emp ex: Employee # HireDate? HireDate. }
Hay tres partes en la consulta. Una secuencia de cláusulas PREFIX

declaran los espacios de nombres. La cláusula SELECT indica el formato
del resultado. La cláusula WHERE en este caso contiene un patrón de
gráfico compuesto por cuatro triples en notación Turtle. Los triples en la
consulta se comparan con los triples en un gráfico RDF que instancia las
variables en el patrón. En nuestro caso, este es el gráfico RDF
predeterminado que representa el almacén de datos de Northwind. Si
queremos incluir otros gráficos, se debe agregar una cláusula FROM,
seguida de una lista de gráficos con nombre. Como hemos visto, la consulta
anterior (sin la parte de prefijo) se puede escribir de manera más sucinta
SELECT? FirstName? LastName? HireDate
DÓNDE { ? emp a ex: Empleado; ej .: Empleado # ¿Nombre? primer Nombre; ej
.: Empleado # ¿Apellido? apellido; ej .: Employee # HireDate?
HireDate.}
A evaluar la consulta anterior, instanciamos la variable? emp con un IRI

cuyo tipo es http://example.org/NWDW#Employee. Luego, miramos si
hay un triple con el mismo sujeto y propiedad, por ejemplo: Empleado #
Nombre y, si es así, instanciamos la variable? Primer Nombre. Procedemos
de manera similar para instanciar las otras variables en la consulta y
devolver el resultado. Tenga en cuenta que, en este caso, el resultado de la
consulta no es un gráfico RDF, sino un conjunto de literales.
Alternativamente, la cláusula CONSTRUCT se puede utilizar para devolver
un gráfico RDF construido mediante la sustitución de variables en un
conjunto de plantillas triples.
De ahora en adelante, omitimos las cláusulas de prefijo en las consultas
por brevedad. La palabra clave DISTINCT debe usarse para eliminar
duplicados en el resultado. Por ejemplo, la siguiente consulta devuelve las
ciudades de los clientes de Northwind, sin duplicados:
SELECT DISTINCT? Ciudad
DÓNDE { ? cliente un ex: cliente; ej .: Cliente # Ciudad? ciudad.}
La palabra clave FILTER selecciona patrones que cumplen una

determinada condición. Por ejemplo, la consulta "Nombre y apellido de los
14.2 5
empleados contratados entre 1992 y 1994" se lee en SPARQL de la
siguiente manera:
SELECCIONAR? Primer nombre? Apellido

¿DÓNDE? Emp a ex: Empleado; ej .: Empleado # ¿Nombre? primer Nombre; ej .:
{
Empleado # ¿Apellido? apellido; ej .: Employee # HireDate? HireDate.
FILTRAR( ?fecha de contratación >= '' 1992-01-01 ''∧∧xsd: fecha
&&
?fecha de contratación <= ''1994-12-31''∧∧xsd: fecha) }
Las condiciones de filtro son expresiones booleanas construidas usando las

conectivas lógicas && (y), (o) y! (no).
|
La palabra clave FILTER se puede combinar con la palabra clave NOT
EXISTS para probar la ausencia de un patrón. Por ejemplo, la consulta
"Nombre y apellido de los empleados sin supervisor" se lee en SPARQL de
la siguiente manera:
SELECCIONAR? Primer nombre? Apellido
¿DÓNDE? Emp a ex: Empleado; ej .: Empleado # ¿Nombre? primer
{
Nombre; ej .: Empleado # ¿Apellido? Apellido .
FILTRO NO EXISTE { ? emp ex: Empleado # Supervisor? sup. }}
La palabra clave OPCIONAL se utiliza para especificar un patrón de

gráfico para el cual se mostrarán los valores si se encuentran. Por ejemplo,
la consulta "Nombre y apellido de los empleados, junto con el nombre y
apellido de su supervisor, si tiene uno" se puede escribir en SPARQL de la
siguiente manera:
SELECCIONE? EmpFirstName? EmpLastName? SupFirstName? SupLastName
DONDE? Emp a ex: Empleado; ej .: Empleado # FirstName? empFirstName
{
;
ej .: Empleado # ¿Apellido? empLastName.
OPCIONAL? Emp ex: Empleado # Supervisor? Sup
{
.
? sup a ex: empleado; ej: Empleado # FirstName?
supFirstName; ej .: Empleado # ¿Apellido? supLastName.}}
Observe que la palabra clave OPCIONAL se comporta de manera similar a

una combinación externa en SQL.
Agregación y clasificación en SPARQL

Las funciones agregadas resumen la información de múltiples patrones
triples en uno solo. SPARQL proporciona las funciones agregadas
habituales COUNT, SUM, MAX, MIN y AVG. Además, siguiendo las líneas
de SQL, antes del resumen, los triples se pueden agrupar usando la palabra
clave GROUP BY, y luego la función agregada se aplica a cada grupo.
Además, el filtrado de grupos también se puede realizar con la palabra
clave HAVING, como se hace con la cláusula FILTER para conjuntos
desagrupados. Finalmente, el resultado se puede ordenar con la cláusula
ORDER BY, donde cada atributo de la lista se puede ordenar en orden
ascendente o descendente especificando ASC o DESC, respectivamente.
Considere la consulta “Número total de pedidos manejados por cada
empleado, en orden descendente de número de pedidos. Solo enumere los
empleados que manejaron más de 100 pedidos ". Esta consulta se expresa
en SPARQL de la siguiente manera:
14.2 5
SELECT? Emp (COUNT (DISTINCT? OrderNo) AS? OrdersByEmployee)
WHERE? Sales a ex: Sales; ej: Ventas # Empleado? emp
{
;
ej .: Sales # OrderNo? orderNo.
? emp a ex: Empleado.
}
AGRUPAR POR? Emp
TENIENDO COUNT (DISTINCT? OrderNo) >
100 ORDER BY DESC (COUNT (DISTINCT?
OrderNo))
La cláusula GROUP BY recoge los pedidos asociados a cada empleado, la

cláusula HAVING conserva solo los empleados que tienen más de 100
pedidos distintos, y la cláusula ORDER BY ordena el resultado en orden
descendente según el número de pedidos.
Considere ahora la consulta “Para clientes de San Francisco, enumere la
cantidad total de cada producto pedido. Ordene el resultado por clave de
cliente, en orden ascendente, y por cantidad de productos solicitados, en
orden descendente ".
SELECCIONE? Cust? Prod (SUM (? Qty) AS? TotalQty)
DONDE? Ventas a ex: Ventas; ej .: Ventas # Cliente
{
? cust;
ej .: Ventas # Producto? prod; Ej .: Ventas # Cantidad? Cant.
cust a ex: cliente; ? ej .: Cliente # Ciudad? ciudad.
? ciudad a ex: Ciudad; ej .: Ciudad # Nombre?
cityName. FILTRO (? CityName =''San
}
Francisco'')
AGRUPAR POR? Cust? Prod
ORDEN POR ASC (? Cust) DESC (? TotalQty)
Esta consulta define un patrón de gráfico que vincula las ventas con los
clientes y las ciudades. Antes de agrupar, necesitamos encontrar los triples
que satisfagan el patrón del gráfico y seleccionar los clientes de San
Francisco. A continuación, agrupamos por pares de? Cust y? Prod y, para
cada grupo, tomamos la suma del atributo? Qty. Finalmente, se ordenan
los triples resultantes.
Subconsultas
En SPARQL, una subconsulta se usa para buscar un cierto valor en una
base de datos y luego usar este valor en una condición de comparación.
Una subconsulta es una consulta encerrada entre llaves que se utilizan
dentro de una cláusula WHERE. La consulta externa se denomina consulta
externa.
Como ejemplo, consideremos la consulta "Para cada cliente, calcule el
monto máximo de ventas entre todos sus pedidos". La consulta se escribe
SELECCIONAR (MAX (? TotalSales) como?
MaxSales) DONDE
{
SELECCIONE? Cust? OrderNo (SUM (? Sales) as? TotalSales)
¿DÓNDE? Ventas un ex: Ventas;
{
ej .: Sales # Customer? cust;
ej .: Sales # OrderNo? orderNo; ej .: Ventas # SalesAmount?
ventas.
cust a ex: cliente.
}
5 AGRUPAR POR? Cust?
14 almacenes de datos y la web semántica
}
OrderNo GROUP BY? Cust
14.3 Representación RDF de datos 5
La consulta interna calcula el monto total de ventas de cada cliente y
pedido. Luego, en la consulta externa, para cada cliente seleccionamos el
monto máximo de venta entre todos sus pedidos.
Las subconsultas se utilizan comúnmente con las palabras clave UNION y
MINUS.
El UNION combina patrones de gráficos para que coincida uno de varios
patrones de gráficos alternativos. Por ejemplo, la consulta "Productos que
han sido pedidos por clientes de San Francisco o suministrados por
proveedores de San José" se puede escribir de la siguiente manera:
SELECT DISTINCT? ProdName
DONDE
{
SELECCIONAR? Prod
¿DÓNDE? Ventas por ejemplo: Ventas; ej .: Ventas #
{
Producto? prod; ex: Sales # Customer? cust
.
cust a ex: cliente; ex: Cliente # Ciudad? custCity.
? custCity a ex: City; ej .: Ciudad # Nombre?
custCityName. FILTRO (? CustCityName =''San
Francisco'') } }
UNIÓN
{
SELECCIONAR? Prod
{
Producto? prod; ej .: Ventas # Proveedor?
sup .
? sup a ex: Proveedor; Ej .: Proveedor # Ciudad? supCiudad.
? supCity a ex: Ciudad; ej .: Ciudad # Nombre?
supCityName. FILTRO (? SupCityName =''San
Jose'') } }}
De manera análoga, la operación MENOS calcula la diferencia entre los
resultados de dos subconsultas. Un ejemplo es la consulta: "Productos que
no han sido pedidos por clientes de San Francisco", que se puede escribir
SELECT DISTINCT? Prod
¿DÓNDE? Ventas por ejemplo: Ventas; ej .: Sales # Product? prod .
{
MENOS
{
SELECCIONAR? Prod
{
Producto? prod; ex: Sales # Customer? cust
.
cust a ex: cliente; ej .: Cliente # Ciudad? ciudad.
? ciudad a ex: Ciudad; ej .: Ciudad #
Nombre? cityName. FILTRO (? CityName
=''San Francisco'') }}}}
La consulta interna calcula los productos pedidos por los clientes de San
Francisco. La consulta externa obtiene todos los productos que se han
pedido y les resta los productos obtenidos en la consulta interna.
14.3 Representación RDF de datos

multidimensionales
Nosotros ahora están listos para estudiar dos enfoques para representar
datos multidimensionales en RDF, a saber, QB y QB4OLAP. Suponga que
la empresa Northwind quiere analizar los datos de ventas con datos
económicos y demográficos,
publicados como datos abiertos en la web. En lugar de cargar y mantener
esos datos de forma permanente en el almacén de datos local, podría ser
más eficiente cargarlos temporalmente en el almacén para su análisis u
operar sobre un cubo directamente en formato RDF, como estudiaremos
en las siguientes secciones. Poder publicar cubos de datos en RDF también
permitirá a la empresa publicar datos en la web para que sean compartidos
por todas las sucursales de la empresa.
En nuestro estudio, utilizaremos una ontología de Ordnance Survey que
contiene la geografía administrativa y las áreas de votación civil en Gran
Bretaña.10 En esta ontología, las unidades administrativas se definen como
clases y la relación geográfica entre ellas se define a través de propiedades.
Por ejemplo, GovernmentO ffi ceRegion (GOR) y UnitaryAuthority (UA)
son clases, mientras que hasGORCode, hasUACode y hasName son
propiedades. La relación entre UA, GOR y países (en el Reino Unido) se da
a nivel de instancia, en lugar de a nivel de esquema. Por ejemplo, la
Autoridad Unitaria de Lectura, con el código 00MC, se encuentra en la
Región de la Oficina de Gobierno del Sureste. A modo de ejemplo,
mostramos a continuación una parte de la ontología correspondiente a
Lectura:
@pre fi x rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
@prefijo id: <http://data.ordnancesurvey.co.uk/id/>
@pre fi x admgeo: <http://data.ordnancesurvey.co.uk/ontology/admingeo/>
@pre fi x skos: <http://www.w3.org/2004/02/skos/core#>
<http://data.ordnancesurvey.co.uk/id/7000000000038895>
a admgeo: Municipio; a admgeo: UnitaryAuthority;
rdf: etiqueta ''El distrito de Reading'' ; admgeo: gssCode''E06000038''
; admgeo: hasAreaCode''UTA'' ; admgeo: hasUACode''00MC'' ; skos:
prefLabel''El distrito de Reading'' .
El IRI en la quinta línea representa el recurso (Lectura), y es el sujeto de

los triples formados con los pares predicado-objeto debajo (indicando, por
ejemplo, que el código de área de Lectura es UTA).
Además, asociado con los datos geográficos anteriores, tenemos datos
anuales sobre hogares en el Reino Unido. Con estos datos, construimos un
cubo de datos denominado HouseholdCS con una medida Household y dos
dimensiones, Geografía y Tiempo. Dimension Geography está organizado
en la siguiente jerarquía de niveles:Autoridad Unitaria
→
GobiernoO ffi ceRegion País
→Todas. Mostramos ejemplos de instancias en la Fig.14,4. Dimension Time
→
tiene la jerarquíaAño Todas. Figura14,5 muestra una
instancia de este cubo de datos, en formato tabular. Por ejemplo, una celda
correspondiente al hogar en Reading en 2006 tiene el valor 58. En las
siguientes secciones, mostramos cómo este cubo de datos puede
definirse en RDF.
10
http://data.ordnancesurvey.co.uk/ontology/admingeo/
Todas todas
País Inglaterra Gales
Gobierno Sur Sur Gales

OficinaRegión este Oeste
Unitario Milton Leer Cardiff Newport

Bourne
Autoridad Keynes -
Figura 14.4 Ejemplos de instancias de la dimensión Geografía
Año
País GOR UA 2006 2007 2008
Milton Keynes 92 94 96
Sureste
Inglater Leer 58 58 60
ra Sur oeste Bournemouth 71 72 73
Cardi ff 132,1 134,2 136,7
Gales Gales
Newport 58,7 59,6
Figura 14.5 Una instancia del cubo de datos HouseholdCS en formato tabular
14.3.1 Vocabulario del cubo de datos RDF

El vocabulario del cubo de datos RDF11 o QB proporciona los medios para
publicar datos estadísticos y metadatos en la web utilizando RDF. Este
vocabulario es compatible con el modelo de cubo subyacente al
intercambio de datos estadísticos y metadatos (SDMX). 12 estándar, un
estándar ISO para intercambiar y compartir datos estadísticos y metadatos
entre organizaciones. Figura14,6 describe el vocabulario QB. Los términos
en mayúscula representan clases de RDF y los términos no en mayúscula
representan propiedades de RDF. Las clases de vocabularios externos se
representan en fuente gris claro en la Fig.14,6.
QB proporciona construcciones para representar la estructura y las
instancias de datos estadísticos. Una definición de estructura de datos
(DSD), definida como una instancia de la clase qb: DataStructureDe fi
nition, especifica el esquema de un conjunto de datos, definido como una
instancia de la clase qb: DataSet. Esta estructura se puede compartir entre
diferentes conjuntos de datos. La DSD de un conjunto de datos se define
mediante la propiedad qb: structure. El DSD tiene propiedades de
componentes para representar
11
http://www.w3.org/TR/vocab-data-cube/
12
http://sdmx.org/?page id = 10
qb: componentRequired: boolean

qb: componentAttachment: rdf:
Class qb: order: xsd: int
qb: qb: componente qb:
qb: componentProperty
qb: estructura qb: sliceKey qb: dimensión qb: atributo
qb: qb: medir
qb: Conjunto de datos qb: SliceKey componentProperty
qb: rebanada qb: qb:

qb: qb: concepto
conjunto sliceStructure
de datos qb:
qb: Observación
skos:
qb: rebanada
qb: qb:
qb: observación qb: subSlice
sdmx:
qb:
sdmx:
FrequenceRole sdmx: qb: codeList
CountRole sdmx:
EntityRole sdmx: sdmx:
TimeRole sdmx: skos:
MeasureTypeRole
sdmx: NonObsTimeRole
sdmx: IdentityRole sdmx: CodeList
sdmx: PrimaryMeasureRole
Figura 14.6 Esquema del vocabulario QB
dimensiones, medidas y atributos, denominados qb: dimensión, qb:

medida y qb: atributo, respectivamente. Las especificaciones de los
componentes están vinculadas a los DSD a través de la propiedad qb:
component. Por ejemplo, el esquema del cubo de datos HouseholdCS de la
Fig.14,5 se puede definir de la siguiente manera:
ej .: Geografía a qb: DimensionProperty, qb: CodedProperty.
ej .: Hora a qb: DimensionProperty, qb: CodedProperty. ej .:
Hogar a qb: MeasureProperty.
ej: HouseholdCS a qb: DataStructureDe fi
nition; qb: componente [qb: dimensión ex:
Geografía]; qb: componente [qb: dimensión
ex: tiempo]; qb: componente [qb: medida
ex: hogar];
qb: componente [qb: atributo sdmx-atributo: unitMeasure].
Para mayor claridad, omita arriba la declaración de los prefijos. Primero, se

definen las dimensiones Geografía y Tiempo, así como la medida del
Hogar. Luego, el esquema del cubo de datos, llamado ex: HouseholdCS, se
declara como una instancia de qb: DataStructureDe fi nition. Las
dimensiones, medidas y atributos se definen utilizando la propiedad qb:
component y utilizando nodos en blanco.
Las observaciones, que son instancias de qb: Observation, representan
puntos en un espacio de datos multidimensional. Se agrupan en conjuntos
de datos mediante la propiedad qb: dataSet. Una observación está
vinculada a un valor en cada dimensión del DSD utilizando propiedades
definidas como instancias de qb: DimensionProperty.
Un conjunto de valores y atributos de medida se asocia con una
observación mediante las propiedades qb: MeasureProperty y qb:
AttributeProperty en el DSD, respectivamente. Una instancia del cubo
anterior se define de la siguiente manera:
ej: dataset-hh a qb: DataSet; rdfs: etiqueta''Hogar en Reino Unido''@en;
qb: estructura ex: HouseholdCS.
ej: o1 a qb: Observación; qb: dataSet ex: dataset-hh; ej .: Geografía ns0:
00mc; ex: Hora<http://dbpedia.org/resource/2007> ; ej .: hogar 58;
atributo sdmx: unitMeasure<http://dbpedia.org/resource/Thousand> .
Aquí, definimos un conjunto de datos ex: dataset-hh, cuya estructura es ex:

HouseholdCS. La observación ex: o1 pertenece a este conjunto de datos.
También se dan los valores de las dimensiones. Tenga en cuenta que el año
2007 se representa mediante un IRI.
QB proporciona la propiedad qb: concept, que vincula los componentes
al concepto que representan. Estos últimos se modelan utilizando la clase
skos: Concept de fi nida en SKOS 13 (Sistema de organización del
conocimiento simple) vocabulario.
Representación de datos multidimensionales en QB
QB no proporciona un mecanismo para representar un esquema

multidimensional, pero nos permite representar relaciones jerárquicas
entre miembros de niveles de dimensión utilizando el vocabulario SKOS.
Un esquema conceptual de SKOS
de fi ne las relaciones semánticas entre conceptos. Los conceptos están
vinculados
a los esquemas de conceptos a los que pertenecen a través de la propiedad
skos: inScheme. Por ejemplo, skos: broader y skos: narrower permiten la
representación de relaciones jerárquicas. Por ejemplo, el triple país skos:
región más estrecha representa una relación jerárquica donde la región
está en un nivel más bajo que el país. Para proporcionar un punto de
entrada a las jerarquías de conceptos más amplias / más estrechas, SKOS
de fi ne una propiedad skos: hasTopConcept. Por lo tanto, las relaciones
jerárquicas entre miembros de dimensión se representan en QB como una
instancia de qb: DimensionProperty con un skos: ConceptScheme
asociado. Se pueden asociar conceptos particulares en el esquema de
conceptos con la propiedad skos: hasTopConcept, lo que indica que estos
valores corresponden a miembros en el nivel más alto de granularidad en
la jerarquía de dimensiones. Se puede llegar a los miembros con niveles
más bajos de granularidad mediante la propiedad skos: narrower. Todo lo
anterior implica que los miembros de dimensión en QB solo se pueden
navegar desde conceptos de granularidad más alta hasta conceptos de
granularidad más fina. Tenga en cuenta que, en general, las operaciones
OLAP comunes (excepto el desglose) atraviesan las jerarquías de
dimensión en la dirección opuesta.
A continuación mostramos un extracto de una dimensión Geografía
construida a partir de
La ontología de Ordnance Survey presentada anteriormente, representada
mediante QB:
ej .: Geografía a qb: DimensionProperty, qb: CodedProperty; qb: codeList ex:
geo. ex: geo a skos: ConceptScheme; skos: hasTopConcept ns2: 921.
13
http://www.w3.org/2009/08/skos-reference/skos.html
ns2: 921 a adgeo: País; rdfs:
etiqueta''Inglaterra''@en; skos: inScheme ex:
geo; skos: más estrecho ns1: J.
ns1: J a adgeo: GovernmentO ffi ceRegion; rdfs:
etiqueta''Sureste''@en; skos: inScheme ex: geo; skos: más
estrecho ns0: 00mc.
ns0: 00mc a adgeo: UnitaryAuthority; rdfs: etiqueta''El distrito de Reading''@en; skos:
inScheme ex: geo.
La dimensión se denota ex: Geography, y se define como miembro de las
clases qb: DimensionProperty y qb: CodedProperty. Esta dimensión está
asociada a un esquema de concepto ex: geo, un miembro de la clase skos:
ConceptScheme, usando la propiedad qb: codeList. Intuitivamente, esta
lista de códigos representa el conjunto de valores de la dimensión,
organizados jerárquicamente utilizando el esquema conceptual. El
miembro de dimensión ns2: 921 se define como el concepto superior en ex:
geo usando la propiedad skos: hasTopConcept. También se afirma que
dicho elemento es una instancia de la clase adgeo: Country, denominada
Inglaterra. Las relaciones jerárquicas entre los miembros se establecen
utilizando la propiedad skos: más estrecha, desde los conceptos más
generales hasta los más específicos, es decir, de adgeo: Country a través de
adgeo: GovernmentO ffi ceRegion a adgeo: UnitaryAuthority.
Remarcamos, una vez más,
Operaciones OLAP sobre QB
En un modelo multidimensional, los hechos representan puntos en un

espacio multidimensional, donde las coordenadas de dimensión se dan en
los niveles más bajos de cada dimensión participante (hemos visto, sin
embargo, en los Capítulos. 4 y 5, que a veces podemos tener hechos con
diferentes granularidades). La especificación QB permite que las
observaciones en diferentes niveles de granularidad coexistan en un
conjunto de datos, lo que hace que las operaciones OLAP sean difíciles de
implementar. Una solución podría ser dividir las observaciones originales
en diferentes conjuntos de datos, cada uno con observaciones con el mismo
nivel de granularidad, lo que no es posible, ya que los niveles de agregación
no se modelan en QB, como ya hemos visto. Como consecuencia, el
vocabulario QB no proporciona soporte directo para las operaciones OLAP.
Además, la posibilidad de implementar operaciones OLAP sobre datos
representados mediante QB tiene algunas limitaciones, que se describen a
continuación.
La operación de acumulación no es compatible con QB debido a lo siguiente.
Primero, la acumulación requiere atravesar una jerarquía de dimensiones
desde un nivel base
hasta un nivel objetivo. Dado que los niveles de dimensión no se modelan
en QB, esta navegación no es compatible. En segundo lugar, la relación
entre los miembros del nivel se modela desde el concepto más general
hasta conceptos más específicos. Finalmente, las funciones agregadas para
cada medida no se modelan y estas funciones son necesarias para
implementar la operación de acumulación. Aunque en las herramientas
OLAP, cada medida está asociada con una función de agregación, esto no
es
abordado en QB. Se aplican observaciones análogas a la operación de
desglose.
Rebanar no se admite en QB debido al hecho de que las funciones
agregadas para una medida determinada no se modelan, y estas funciones
son necesarias para reducir
a un solo valor la dimensión que se eliminará, como se explica en el Cap. 3.
Cortar en cubitos es compatible con QB. Por ejemplo, la cláusula FILTER
en SPARQL se puede utilizar para implementar una condición de corte en
cubos.
Dadas las limitaciones comentadas anteriormente, para poder de fi nir e
implementar operaciones OLAP, debemos extender QB para soportar
jerarquías de dimensión. A continuación, explicamos cómo se puede hacer
esto.
14.3.2 Vocabulario QB4OLAP

El vocabulario QB4OLAP 14 tiene como objetivo dar una solución a los
problemas del vocabulario QB discutidos en la sección anterior. Los datos
multidimensionales se pueden publicar en QB4OLAP desde cero, o los
datos ya publicados mediante QB se pueden ampliar con niveles de
dimensión, miembros de nivel, jerarquías de dimensión y la asociación de
funciones agregadas a medidas sin afectar las observaciones existentes. Por
lo tanto, los cubos de datos ya publicados usando QB también pueden
representarse usando QB4OLAP sin afectar las aplicaciones existentes
desarrolladas sobre cubos de datos QB.
Figura 14,7 describe el vocabulario QB4OLAP. Las clases y propiedades
agregadas a QB (con prefijo qb4o) se representan con fondo gris claro y
fuente negra. La clase qb4o: LevelProperty modela niveles de dimensión.
Las relaciones entre los niveles de dimensión se representan mediante la
propiedad qb4o: parentLevel. Los miembros de nivel se representan como
instancias de la clase qb4o: LevelMember, y las relaciones entre ellos se
pueden expresar utilizando la propiedad skos: broader. Los atributos de
nivel se definen mediante la propiedad qb4o: hasAttribute. Las
propiedades de nivel se establecen en la definición de estructura de datos.
La clase qb4o: AggregateFunction representa funciones agregadas. La
asociación entre medidas y funciones agregadas se representa mediante la
propiedad qb4o: hasAggregateFunction. Esta propiedad, junto con el
concepto de conjuntos de componentes,
Representación de datos multidimensionales en QB4OLAP
Nosotros A continuación, se muestra cómo se puede utilizar QB4OLAP para

publicar datos multidimensionales desde cero. A continuación se muestra
la definición del esquema de la dimensión Geografía utilizando QB4OLAP:
ej .: Geografía a qb: DimensionProperty.
ex: UnitaryAuthority a qb4o: LevelProperty; qb4o: inDimension ex: Geografía; qb4o:
parentLevel ex: GovernmentO ffi ceRegion.
ej: GovernmentO ffi ceRegion a qb4o: LevelProperty; qb4o: inDimension ex: Geografía;
qb4o: parentLevel ex: País.
14
http://purl.org/qb4olap/cubes
qb4o:
rdf: tipo qb4o: hasAggregateFunction
qb: componentRequired: boolean

qb4o: qb4o: qb4o:
qb: componentAttachment: rdf:
qb4o: qb4o: Class qb: order: xsd: int
qb:
qb: componente
qb: dimensión qb:
atributo qb: medida
qb: estructura qb: sliceKey qb4o: nivel
qb: Conjunto de datos qb: SliceKey
qb:
qb: qb: rebanada qb: qb4o: inLevel

conjunto concepto qb4o: h asAttribute
de datos
qb: Observación qb: rebanada qb4o: LevelProperty
qb4o:
qb4o: inDimension
qb: qb: skos: más amplio qb4o: parentLevel
observación subSlice
skos:
qb:
sdmx:
qb: qb:
sdmx: FrequenceRole
sdmx:
qb:
CountRole sdmx: sdmx: qb: codeList
EntityRole sdmx: TimeRole
sdmx: MeasureTypeRole
sdmx: NonObsTimeRole skos:
sdmx: IdentityRole sdmx:
PrimaryMeasureRole
sdmx: CodeList
Figura 14.7 Esquema del vocabulario QB4OLAP
ej .: País a qb4o: LevelProperty; qb4o: inDimension ex: Geografía;

skos: closeMatch adgeo: País.
Los niveles ex: UnitaryAuthority, ex: GovernmentO ffi ceRegion y ex: Country

son definidas como instancias de la clase qb4o: LevelProperty, y la relación
entre ellas está definida por la propiedad qb4o: parentLevel.
A continuación, se muestra una instancia de la dimensión Geografía:
ns0: 00mc qb4o: inLevel ex: UnitaryAuthority;
rdfs: etiqueta ''El distrito de Reading''@en; skos: broader ns1:
J. ns1: J qb4o: inLevel ex: GovernmentO ffi ceRegion;
rdfs: etiqueta ''Sureste''@en; skos: más amplio ns2: 921.
ns2: 921 qb4o: inLevel ex: País; rdfs:
etiqueta''Inglaterra''@en.
La propiedad qb4o: inLevel indica el nivel en la jerarquía al que pertenece

un miembro de nivel, mientras que skos: broader de fi ne el padre de un
miembro de nivel. Por ejemplo, se indica que el miembro ns1: J pertenece
al nivel ex: GovernmentO ffi ceRegion y que dicho miembro se suma al
miembro ns2: 921 en el nivel ex: Country. Tenga en cuenta que las
instancias de dimensión se tratan de forma análoga a QB, utilizando el
vocabulario de SKOS.
El cubo de datos de la Fig. 14,5 se puede representar usando QB4OLAP de
la siguiente manera:
ej .: Geografía a qb: DimensionProperty.
ex: Time a qb: DimensionProperty.
ex: Año a qb4o: LevelProperty; skos: closeMatch db: Año; qb4o: inDimension ex:
Time. ej .: Hogar a qb: MeasureProperty.
Ej: HouseholdCS a qb: DataStructureDe fi nition; qb:
componente [qb4o: nivel ex: UnitaryAuthority];
qb: componente [qb4o: nivel ex: año];
qb: componente [qb: medida ex: hogar; qb4o: hasAggregateFunction qb4o: suma].
Hay algunas diferencias relevantes con el cubo de datos QB que se muestra

en la sección anterior. El esquema del cubo de datos se declara como una
instancia de la clase qb: DataStructureDe fi nition. La propiedad de nivel
qb4o: level se utiliza para especificar los niveles en el esquema del cubo.
Por ejemplo, el triple ex: HouseholdCS qb: componente [qb4o: level ex:
Year] indica que ex: Year es un nivel del cubo. De manera análoga, el triple
ex: Household a qb: MeasureProperty dice que ex: Household es una
medida en el cubo, como en QB. Además, la función agregada
correspondiente a esta medida se define mediante la propiedad qb4o:
hasAggregateFunction.
Una instancia del cubo se representa en QB4OLAP de la siguiente
manera:
ej: dataset-hh a qb: DataSet; qb: estructura ex:
HouseholdCS; rdfs: etiqueta''Hogar en Reino Unido''@en.
ej: o1 a qb: Observación; qb: dataSet ex: dataset-hh; ej .:
UnitaryAuthority ns0: 00mc; ej .: Año db: 2007; ej .: hogar 58.
El conjunto de datos ex: dataset-hh se define como una instancia de la

clase qb: DataSet, vinculado al cubo de datos mediante la propiedad qb:
structure. Además, una observación ex: o1 se define como una instancia de
la clase qb: Observación. La instancia representa la celda del cubo con
valores ns0: 00mc para UA, 2007 para Año y 58 para la medida Hogar.
Tenga en cuenta que las observaciones se definen utilizando clases y
propiedades QB. Por lo tanto, las observaciones en un cubo existente
expresadas en QB no necesitan cambiarse para expresar el cubo en
QB4OLAP.
Operaciones OLAP sobre QB4OLAP
Ahora mostramos una posible implementación de algunas de las

operaciones OLAP sobre un cubo de datos definido usando el vocabulario
QB4OLAP. Las operaciones están escritas en SPARQL.
Nosotros comience con la operación ROLLUP. Como ejemplo, considere

la consulta "Total de hogares por región de oficina gubernamental". Esto se
expresa utilizando las operaciones introducidas en el Cap.3 como
ROLLUP (HouseholdCS, Geografía → GOR, SUM (Hogar)).
La estructura del resultado representado como un esquema QB4OLAP

denotado por ex: HouseholdByGOR se muestra a continuación:
ej: HouseholdByGOR a qb: DataStructureDe fi nition; qb:
componente [qb4o: nivel ex: GovernmentO ffi
ceRegion]; qb: componente [qb4o: nivel ex: año];
qb: componente [qb: medida ex: hogar; qb4o: hasAggregateFunction qb4o:
suma]. ej: dataset-hh1 a qb: DataSet; rdfs: etiqueta''Hogar en Reino Unido por
GOR''@en;
qb: estructura ex: HouseholdByGOR.
La consulta SPARQL que implementa la operación se muestra a

continuación:
CONSTRUIR? Id a qb: Observación; qb: dataSet ex: dataset-hh1; ex: año? año;
{
ej .: GovernmentO ffi ceRegion? gor; ej .: hogar? resumen.
}
DÓNDE
{
SELECT? Gor? Year (SUM (? Hhold) AS? SumHhold) (iri (concat
(''http://example.org/hhold#Roll-upGOR '', strafter (?
gor, ''http://example.org/hhold#''), '' '', strafter (?
año, ''http://example.org/hhold#''))) AS? Id)
¿DÓNDE? O qb: dataSet ex: dataset-hh;
{
ex: año? año ; ej: hogar? hhold; ex:
UnitaryAuthority? ua.
? ua skos: más amplio? gor.
? gor qb4o: inLevel ex: GovernmentO ffi ceRegion. }
GRUPO POR? Gor? Año }}
En la cláusula WHERE de la subconsulta, se realiza una coincidencia de

patrones de gráficos. A partir de las triples coincidentes, los valores que
instancian las variables? Gor y? Year se devuelven y se agregan en la
cláusula SELECT. Es importante resaltar que se deben generar nuevos IRI
para identificar cada una de las nuevas observaciones resultantes de la
aplicación de la operación. Esto se hace en la cláusula SELECT de la
subconsulta con la función strafter, que devuelve la subcadena del primer
parámetro que aparece después de la cadena en el segundo parámetro.
Además, en la consulta externa, se usa la cláusula CONSTRUCT ya que
devuelve un gráfico, opuesto a la cláusula SELECT, que devuelve literales.
Consideremos ahora la siguiente operación de corte:
SLICE (Ventas, Geografía, País =''Inglaterra''),
que elimina la dimensión Geografía fijando un valor en ella. Como en el

caso anterior, primero necesitamos definir el esquema del cubo resultante
ej: HouseholdSlice a qb: DataStructureDe fi nition;
qb: componente [qb4o: nivel ex: año];
qb: componente [qb: medida ex: hogar; qb4o: hasAggregateFunction qb4o:
suma]. ej: dataset-hh2 a qb: DataSet; rdfs: etiqueta''Hogares en Inglaterra por
año''@es ;
qb: estructura ex: HouseholdSlice.
14.4 Representación del cubo de Northwind en QB4OLAP 5
Nosotros denotar este cubo como ex: HouseholdSlice. Podemos ver que el
cubo resultante solo tiene la dimensión Tiempo (nivel ej .: Año) y ej .:
Medida del hogar. La consulta SPARQL que implementa la operación de
corte se muestra a continuación:
CONSTRUIR? Id a qb: Observación; qb: dataSet ex: dataset-hh2; ex: año? año;
{
ej .: hogar? resumen.
}
DÓNDE
{
SELECT? Year (SUM (? Hhold) AS? SumHhold) (iri (concat
(''http://example.org/hhold#SliceGeo '', strafter (?
año, ''http://example.org/hhold#''))) AS? Id)
¿DÓNDE? O qb: dataSet ex: dataset-hh;
{
ex: año? año ; ex: UnitaryAuthority? ua; ej .:
hogar?
? ua: qb4o: inLevel ex: UnitaryAuthority; skos: más amplio? gor.
? gor: qb4o: inLevel ex: GovernmentO ffi
ceRegion; skos: ¿más amplio? país.
? país: qb4o: inLevel ex: País; rdfs: label? countryLabel.
FILTRO (? CountryLabel =''Inglaterra''@en) }
GRUPO POR? Año }}
Dado que las observaciones se encuentran en la granularidad de la

autoridad unitaria, en la subconsulta debemos pasar al nivel de país.
Entonces, la condición de FILTRO implementa la operación de corte. La
cláusula SELECT de la subconsulta agrega todas las observaciones
pertenecientes a Inglaterra a nivel de año. Como en la consulta anterior, los
IRI de la nueva consulta se generan en la cláusula SELECT de la
subconsulta.
Finalmente, considere la siguiente operación de dados:
DICE (HouseholdCS, Time.Year > 2007),
que obtiene un subcubo del cubo de datos HouseholdCS que solo contiene
datos de 2007 en adelante. Esto se implementa mediante la siguiente
consulta:
CONSTRUIR? Id a qb: Observación; qb: dataSet ex: dataset-hh ;
{
ex: año? año; ex: UnitaryAuthority? ua; ej .: hogar?
}
DÓNDE
{
SELECCIONAR? Ua? Año? Hhold
(iri (concat (''http://example.org/hhold#Dice '',
strafter (? ua, ''http://example.org/hhold#''), '' '',
strafter (? año, ''http://example.org/hhold#''))) AS?
Id)
DÓNDE ? o qb: dataSet ex: dataset-hh; ex: año?
{
año; ej: hogar? hhold; ex: UnitaryAuthority?
ua. FILTRO (? Año>= 2007) } }}
Como se muestra arriba, la condición de dado es implementada por la
cláusula FILTER. Tenga en cuenta que el esquema de salida es idéntico al
esquema de cubo.
14.4 Representación del cubo de Northwind

en QB4OLAP
En esta sección, mostramos cómo el cubo de datos Northwind se puede

representar en RDF usando el vocabulario QB4OLAP. El cubo de datos
Northwind se ha introducido en la Fig.4.2. Lo mostramos de nuevo en la
Fig.14,8 para facilitar la legibilidad.
Empleado
Ciu
Territori
ID de
empleado Proveedor dad
Nombre CityName
Identificación
Apellido
Geografí
del proveedor
Título Fecha
Nombre de la
de
empresa Expresar
nacimiento
Dirección
Fecha de
Código postal Nombre del Estado
contratación
EnglishStateName
Fecha
StateType StateCode
Dirección Cliente StateCapital
Ciudad
Geografí
Región Identificación
PostalCode del cliente
Supervi
País Nombre de la Región

Supervisión empresa
Dirección RegionName
Subordinar Código postal RegionCod
Hora
Fecha Canti
DayNbWeek
dad de
ventas
DayNameWeek Fecha de Precio por unidad:
DíaNbMes orden
Promedio +! Descuento:
DíaNbAño Promedio +!
Fecha de País
Cantidad de ventas
vencimie
nto Nombre del país
WeekNbYear Código de país
Fecha de envío
País Capital
/Importe neto
Calendario Subdivisión de
población
Mes
Producto
Continente
MonthNumber
MonthName ID del Producto
ContinentName
Nombre del
producto
Quarter CantidadPerUni
dadUnidadPreci
Quarter o Descatalogado
Expedidor
Categorias
ShipperID Nombre
Semestre de empresa
Categoría
Semestre
Categoria ID Pedido
Categoría
Año Nombre N º de pedido
Descripción OrderLineNo
Año
Figura 14.8 Esquema conceptual del almacén de datos de Northwind (repetido de

la Fig. 4.2)
Comenzamos por definir los prefijos del espacio de nombres de la

siguiente manera:
@pre fi x qb: <http://purl.org/linked-data/cube#>.
@pre fi x qb4o:<http://purl.org/qb4olap/cubes#> .
@pre fi x nw: <http://dwbook.org/cubes/schemas/northwind#> .
@pre fi x nwi:<http://dwbook.org/cubes/instances/northwind#> .
@pre fi x rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @pre
fi x rdfs:<http://www.w3.org/2000/01/rdf-schema#> .
@pre fi x sdmx-concept: <http://purl.org/linked-data/sdmx/2009/concept#> .
@pre fi x sdmx-dimension: <http://purl.org/linked-data/sdmx/2009/dimension#> .
@pre fi x skos:<http://www.w3.org/2004/02/skos/core#> .
@pre fi x db: <http://dbpedia.org/resource/> .
Las dimensiones se definen utilizando la propiedad qb: DimensionProperty

nw: Empleado a rdf: Propiedad, qb: DimensionProperty; rdfs: etiqueta''Empleado''@en.
nw: OrderDate a rdf: Property, qb: DimensionProperty; rdfs: etiqueta''Fecha de
orden''@en;
rdfs: subPropertyOf sdmx-dimension: refPeriod;
qb: concepto sdmx-concept: refPeriod.
nw: DueDate a rdf: Property, qb: DimensionProperty; rdfs: etiqueta''Fecha de
vencimiento''@en; rdfs: subPropertyOf sdmx-dimension: refPeriod;
qb: concepto sdmx-concept: refPeriod. nw:
ShippedDate a rdf: Property, qb: DimensionProperty;
rdfs: etiqueta ''Fecha de envío''@en; rdfs: subPropertyOf sdmx-dimension:
refPeriod; qb: concepto sdmx-concept: refPeriod.
nw: Producto a rdf: Propiedad, qb: DimensionProperty; rdfs:
etiqueta''Producto''@en. nw: Solicite un rdf: Property, qb: DimensionProperty;
rdfs: etiqueta''Pedido''@en. nw: Remitente a rdf: Property, qb:
DimensionProperty; rdfs: etiqueta''Expedidor''@en. nw: Cliente a rdf: Propiedad,
qb: DimensionProperty; rdfs: etiqueta''Cliente''@en. nw: Proveedor a rdf:
Propiedad, qb: DimensionProperty; rdfs: etiqueta''Proveedores''@en.
Un cubo se define usando la propiedad qb: DataStructureDe fi nition, y

sus dimensiones se definen usando la propiedad qb4o: level, de la siguiente
manera:
nw: Northwind a qb: DataStructureDe fi nition;
qb: componente [qb4o: nivel nw: empleado];
qb: componente [qb4o: level nw:
OrderDate]; qb: componente [qb4o: level
nw: DueDate]; qb: componente [qb4o: level
nw: ShippedDate]; qb: componente [qb4o:
nivel nw: producto]; qb: componente [qb4o:
level nw: Order]; qb: componente [qb4o:
level nw: Shipper]; qb: componente [qb4o:
nivel nw: Proveedor]; qb: componente [qb4o:
level nw: Customer];
Las medidas se definen utilizando la propiedad qb: medida, donde la

función agregada asociada con cada medida se define utilizando la
propiedad qb4o: hasAggregateFunction:
qb: componente [qb: medida nw: cantidad;
qb4o: hasAggregateFunction qb4o:
suma];
qb: componente [qb: medida nw: UnitPrice;
qb4o: hasAggregateFunction qb4o: avg];
qb: componente [qb: medida nw: descuento;
qb4o: hasAggregateFunction qb4o: avg];
qb: componente [qb: medida nw:
SalesAmount; qb4o:
hasAggregateFunction qb4o: suma];
qb: componente [qb: medida nw: flete; qb4o:
hasAggregateFunction qb4o: suma];
qb: componente [qb: medida nw:
NetAmount; qb4o:
hasAggregateFunction qb4o: suma].
A continuación, usamos la dimensión Producto para ilustrar cómo de fi nir

dimensiones. Los atributos de los niveles se definen con la propiedad qb:
AttributeProperty de la siguiente manera:
nw: ProductKey a qb: AttributeProperty; rdfs: comentario''Clave de producto''@en.
nw: ProductName a qb: AttributeProperty; rdfs: comentario''nombre del
producto''@en. nw: QuantityPerUnit a qb: AttributeProperty; rdfs:
comentario''Cantidad por unidad''@en. nw: UnitPrice a qb: AttributeProperty; rdfs:
comentario''Precio unitario''@en. nw: discontinuado a qb: AttributeProperty; rdfs:
comentario''Interrumpido''@en. nw: CategoryName a qb: AttributeProperty; rdfs:
comentario''nombre de la categoría''@en. nw: Descripción a qb: AttributeProperty;
rdfs: comentario''Descripción''@en.
Una dimensión se define con la propiedad qb: DimensionProperty. Un

nivel de dimensión se define con la propiedad qb4o: LevelProperty, y la
dimensión asociada se define con la propiedad qb4o: inDimension. La
propiedad qb4o: hasAttribute se utiliza para asociar los atributos con un
nivel de dimensión. La de fi nición de la dimensión del Producto se
muestra a continuación:
nw: ProductDim a rdf: Property, qb: DimensionProperty;
rdfs: etiqueta''Dimensión del producto''@en;
nw: Producto a qb4o: LevelProperty; qb4o: inDimension nw: ProductDim; qb4o:
hasAttribute nw: ProductKey; qb4o: hasAttribute nw: ProductName; qb4o:
hasAttribute nw: CantidadPerUnidad; qb4o: hasAttribute nw: Discontinuado;
qb4o: parentLevel nw: Categoría.
nw: Categoría a qb4o: LevelProperty; qb4o: inDimension nw: ProductDim;
qb4o: hasAttribute nw: CategoryName; qb4o: hasAttribute nw:
Descripción.
Las otras dimensiones y niveles se definen de forma análoga.
14.5 Consultar el cubo de Northwind en SPARQL
Dado el esquema del cubo Northwind en la Fig. 14,8 expresado en

QB4OLAP, revisamos las consultas de la Sect. 4.4 en SPARQL.
Consulta 14.1. Monto total de ventas por cliente, año y categoría de
producto.
SELECT? CustName? CatName? YearNo (SUM (? Sales) AS?
TotalSales) WHERE? O qb: dataSet nwi: dataset1; nw: cliente?
{
cliente ;
nw: OrderDate? odate; nw: producto? prod; nw: SalesAmount? ventas.
? cust qb4o: inLevel nw: Cliente; nw: companyName? custName.
? odate qb4o: inLevel nw: OrderDate; skos: ¿más amplio? mes.
? mes qb4o: inLevel nw: mes; skos: un cuarto más amplio.
? trimestre qb4o: inLevel nw: trimestre; skos: ¿más amplio? sem.
? sem qb4o: inLevel nw: Semestre; skos: año más amplio.
? año qb4o: inLevel nw: año; nw: año? año No.
? prod qb4o: inLevel nw: Producto; skos: ¿más amplio? cat.
? cat qb4o: inLevel nw: Categoría; nw: categoryName? catName.
}
AGRUPAR POR? CustName? CatName?
YearNo ORDER BY? CustName?
CatName? YearNo
14.5 Consultar el cubo Northwind en SPARQL 5
En esta consulta, seleccionamos el cliente, la fecha del pedido, el producto
y el monto de ventas de todas las ventas, acumulamos la fecha al nivel de
año, acumulamos el producto al nivel de categoría y agregamos la medida
del monto de ventas.
Consulta 14.2. Importe de las ventas anuales para cada par de países
clientes y países proveedores.
SELECT? CustCountryName? SupCountryName? YearNo (SUM (? Ventas) AS?
TotalSales) ¿DÓNDE? O qb: dataSet nwi: dataset1; nw: cliente? cliente; nw:
{
Proveedor? sup ;
nw: OrderDate? odate; nw: SalesAmount? ventas.
? cust qb4o: inLevel nw: Cliente; skos: más amplia? custCity.
? custCity qb4o: inLevel nw: Ciudad; skos: broader? custState.
? custState qb4o: inLevel nw: State.
? custState skos: más amplio? custRegion.
{
? custRegion qb4o: inLevel nw: Región; skos: más amplio?
}
custCountry. UNION? CustState skos: más amplio? CustCountry
{ }
.
? custCountry qb4o: inLevel nw: País; nw: countryName? custCountryName.
? sup qb4o: inLevel nw: Proveedor; skos: ¿más amplia? supCity.
? supCity qb4o: inLevel nw: Ciudad; skos: ¿más amplio? supState.
? supState qb4o: inLevel nw: State.
? supState skos: más amplio? supRegion.
{
? supRegion qb4o: inLevel nw: Región; skos: más amplio?
}
supCountry. UNION? SupState skos: más amplio? SupCountry
{ }
.
? supCountry qb4o: inLevel nw: País; nw: countryName? supCountryName.
}
GROUP BY? CustCountryName? SupCountryName?
YearNo ORDER BY? CustCountryName?
SupCountryName? YearNo
La consulta anterior realiza un resumen de las dimensiones de cliente y

proveedor al nivel de país y un resumen de la fecha del pedido al nivel de
año y luego agrega el monto de ventas de la medida. Dado que un estado se
suma a una región o un país, los patrones entre llaves antes y después del
operador UNION son necesarios para tener en cuenta ambas rutas de
agregación alternativas.
Consulta 14.3. Ventas mensuales por estado de cliente respecto a las del
año anterior.
SELECCIONAR? StateName? YearNo? MonthNo? TotalSales?
SalesPrevYear WHERE
{
# Ventas mensuales por estado
SELECT? StateName? YearNo? MonthNo (SUM (? Sales) AS?
{
TotalSales) WHERE? O qb: dataSet nwi: dataset1; nw: cliente? cliente
{
;
? cust qb4o: inLevel nw: Cliente; skos: ¿más amplia? ciudad.
? ciudad qb4o: inLevel nw: Ciudad; skos: ¿más amplio?
? estado qb4o: inLevel nw: estado; nw: stateName? stateName.
? mes qb4o: inLevel nw: mes; skos: un cuarto más amplio;
nw: monthNumber? monthNo.

}
GROUP BY? StateName? YearNo? MonthNo
}
# Ventas mensuales por estado para el año
anterior OPCIONAL
{
SELECT? StateName? YearNo1? MonthNo
{
(SUM (? Sales1) AS?
SalesPrevYear)
¿DÓNDE? O1 qb: dataSet nwi: dataset1; nw: cliente? cust1
{
; nw: OrderDate? odate1; nw: SalesAmount?
sales1.
? cust1 qb4o: inLevel nw: Cliente; skos: ¿más amplia? city1.
? city1 qb4o: inLevel nw: Ciudad; skos: ¿más amplio?
? estado qb4o: inLevel nw: estado; nw: stateName? stateName.
? odate1 qb4o: inLevel nw: OrderDate; skos: más amplio? mes1.
? mes1 qb4o: inLevel nw: mes; skos: más amplio? trimestre1; nw:
monthNumber? monthNo.
? trimestre1 qb4o: inLevel nw: trimestre; skos: más amplio? sem1.
? sem1 qb4o: inLevel nw: Semestre; skos: más amplio? año1.
? year1 qb4o: inLevel nw: Año; nw: año? añoNo1.
}
AGRUPAR POR? StateName? YearNo1? MonthNo
}
FILTER (? YearNo =? YearNo1 + 1)
}
ORDER BY? StateName? YearNo? MonthNo
La primera consulta interna calcula las ventas mensuales por estado

acumulando la dimensión del cliente al nivel del estado y la dimensión de
la fecha del pedido al nivel del mes. Luego, después de la palabra clave
OPCIONAL, la segunda consulta interna calcula nuevamente las ventas
mensuales por estado. La condición FILTRO realiza la unión de las dos
consultas internas que relacionan el monto de ventas de un mes y el del
mes correspondiente del año anterior.
Consulta 14.4. Crecimiento de ventas mensuales por producto, es decir,
ventas totales por producto en comparación con las del mes anterior.
SELECT? ProdName? YearNo? MonthNo? TotalSales? PrevMonthSales (?
TotalSales -? PrevMonthSales AS? SalesGrowth)
DÓNDE
{
# Ventas mensuales por producto
SELECCIONAR? ProdName? YearNo? MonthNo (SUM (? Sales) AS ?
{
totalSales) ¿DÓNDE? o qb: dataSet nwi: dataset1; nw: producto? prod
{
;
? prod qb4o: inLevel nw: Producto; nw: productName? prodName.
? mes qb4o: inLevel nw: mes; nw: monthNumber? monthNo; skos: un
cuarto más amplio.
}
AGRUPAR POR? ProdName? YearNo? MonthNo
}
# Ventas mensuales por producto del mes
anterior OPCIONAL
{
SELECCIONAR? ProdName? YearNo1? MonthNo1
{
(SUM (? Sales1) AS? PrevMonthSales)
¿DÓNDE? O1 qb: dataSet nwi: dataset1; nw: producto?
{
prod; nw: OrderDate? odate1; nw: SalesAmount?
sales1 .
? mes1 qb4o: inLevel nw: mes; nw: monthNumber? monthNo1; skos:
más amplio? trimestre1.
}
AGRUPAR POR? ProdName? YearNo1? MonthNo1
}
FILTRO (((? MonthNo =? MonthNo1 + 1) && (? YearNo =? YearNo1))
|
((? MonthNo = 1) && (? MonthNo1 = 12) &&
(? yearNo =? yearNo1 + 1)))
}
ORDER BY? prodName? yearNo? monthNo
La primera consulta interna calcula las ventas mensuales por producto.

Luego, después de la palabra clave OPCIONAL, la segunda consulta interna
calcula nuevamente las ventas mensuales por producto. La condición
FILTRO realiza la unión de las dos consultas internas que relacionan el
monto de ventas de un mes y el del mes anterior. La condición debe tener
en cuenta si el mes anterior es del mismo año o del año anterior.
Consulta 14.5. Tres empleados más vendidos.
SELECT? FName? LName (SUM (? Sales) AS?
TotalSales)
¿DÓNDE? O qb: dataSet nwi: dataset1; nw: empleado? emp; nw: SalesAmount? ventas
{
.
? emp qb4o: inLevel nw: Empleado; nw: firstName? fName; nw:
apellido? lName.
}
AGRUPAR POR? FName?
LName ORDEN POR DESC (?
TotalSales) LÍMITE 3
Esta consulta calcula las ventas totales por empleado, las clasifica en orden
descendente de las ventas totales y conserva los tres primeros resultados.
Consulta 14.6. Empleado más vendido por producto y año.
SELECT? ProdName? YearNo? MaxSales? FName?
LName WHERE
{
# Ventas máximas de empleados por producto y año
SELECCIONE? ProdName? YearNo (MAX (? TotalSales) as?
{
MaxSales) DONDE
{
SELECT? ProdName? YearNo? Emp (SUM (? Sales) AS?
{
TotalSales) WHERE? O qb: dataSet nwi: dataset1; nw: producto?
{
prod; nw: OrderDate? odate; nw: empleado? emp ;
nw: SalesAmount? ventas.
? emp qb4o: inLevel nw: Empleado.
? año qb4o: inLevel nw: año; nw: año? año No.}
AGRUPAR POR? ProdName? YearNo? Emp }}
AGRUPAR POR? ProdName? Año No

}
# Ventas por producto, año y empleado
SELECT? ProdName? YearNo? FName? LName
{
(SUMA (? Ventas1) AS? EmpVentas)
¿DÓNDE? O1 qb: dataSet nwi: dataset1; nw: producto?
{
prod; nw: OrderDate? odate1; nw: ¿Empleado?
emp1; nw: SalesAmount? sales1 .
? emp1 qb4o: inLevel nw: Empleado; nw: firstName? fName; nw:
apellido? lName.
? mes1 qb4o: inLevel nw: mes; skos: más amplio? trimestre1.
? sem1 qb4o: inLevel nw: Semestre; skos: año más amplio.
}
AGRUPAR POR? ProdName? YearNo? FName?
}
LName FILTER (? MaxSales =? EmpSales)
}
ORDER BY? ProdName? YearNo
La primera consulta interna calcula las ventas máximas de los empleados

por producto y año. Luego, la segunda consulta interna calcula las ventas
por producto, año y empleado. La condición FILTRO realiza la unión de las
dos consultas internas que relacionan las ventas máximas con el empleado
que realizó esas ventas.
Consulta 14.7. Países que representan el 50% superior del monto de las
ventas.
Por simplicidad, en esta consulta calculamos el 50% superior del monto
de las ventas por estado, en lugar de por país. En este caso, no debemos
ocuparnos del hecho de que los estados se acumulan en regiones o países.
Esto se puede solucionar utilizando un operador UNION como hicimos en
la Consulta 14.2.
SELECCIONAR? StateName? TotalSales? CumSales
¿DÓNDE? Estado qb4o: inLevel nw: State; nw: stateName? stateName
{
. # Ventas totales y ventas acumuladas por estado
SELECCIONAR? Estado? TotalSales (SUM (? TotalSales1) AS?
{
CumSales) DONDE
{
# Ventas totales por estado
SELECCIONAR? Estado (SUM (? Ventas) AS? TotalSales)
{
¿DÓNDE? O qb: dataSet nwi: dataset1; nw: cliente? cliente
{
; nw: SalesAmount? ventas.
? cust qb4o: inLevel nw: Cliente; skos: ¿más amplia? ciudad.
? estado qb4o: inLevel nw: estado.
}
AGRUPAR POR? Estado
}
# Ventas totales por estado
SELECT? State1 (SUM (? Sales1) AS? TotalSales1)
{
¿DÓNDE? O qb: dataSet nwi: dataset1; nw: cliente? cust1
{
; nw: SalesAmount? sales1.
? city1 qb4o: inLevel nw: Ciudad; skos: más amplio? state1.
? state1 qb4o: inLevel nw: estado. }
AGRUPAR POR? Estado1 }
FILTRO (? TotalSales <=? totalSales1)}
GROUP BY? State? TotalSales }
# Ventas mínimas acumuladas >= 50% de las ventas
totales SELECT (MIN (? CumSales2) AS? Umbral)
{
DÓNDE
{
# 50% de las ventas totales
SELECT (0.5 * SUM (? Ventas) AS?
{
HalfOverallSales) ¿DÓNDE? O qb: dataSet nwi:
{
dataset1 ;
nw: SalesAmount? ventas.
}
# Ventas totales y ventas acumuladas
por estado SELECT? State2?
{
TotalSales2
(SUM (? TotalSales3) AS? CumSales2)
DÓNDE
{
SELECT? State2 (SUM (? Sales2) AS?
{
TotalSales2) WHERE? O2 qb: dataSet nwi:
{
dataset1; nw: Cliente? cust2; nw: SalesAmount?
sales2 .
? city2 qb4o: inLevel nw: Ciudad; skos: más amplio? state2.
? state2 qb4o: inLevel nw:
}
estado. AGRUPAR POR? Estado2
}
SELECT? State3 (SUM (? Sales3) AS?
{
TotalSales3) WHERE? O3 qb: dataSet nwi:
{
dataset1; nw: Cliente? cust3; nw: SalesAmount?
sales3 .
? city3 qb4o: inLevel nw: Ciudad; skos: ¿más amplio? state3.
? state3 qb4o: inLevel nw:
}
estado. AGRUPAR POR? Estado3
}
FILTRO (? TotalSales2 <=? totalSales3)
}
GROUP BY? state2? totalSales2
}
FILTRO (? CumSales2 >=?
}
halfOverallSales) FILTER (? cumSales <=? umbral)
}
ORDEN POR DESC (? TotalSales)
La primera consulta interna calcula para cada país las ventas totales y las
ventas acumuladas de todos los países que tienen ventas totales mayores o
iguales a las ventas totales del país. La segunda consulta interna calcula el
valor de umbral, que representa las ventas acumuladas mínimas mayores o
iguales al 50% de las ventas totales. Finalmente, el FILTRO selecciona
todos los países cuyas ventas acumuladas son menores o iguales al valor
umbral.
Consulta 14.8. Ventas totales y ventas medias mensuales por empleado y
año.
SELECT? FName? LName? YearNo (SUM (? MonthlySales) AS? TotalSales) (AVG (?
MonthlySales) AS? AvgMonthlySales)
DÓNDE
{
# Ventas mensuales por empleado
SELECT? FName? LName? Month (SUM (? Sales) AS? MonthSales)
{
¿DÓNDE? O qb: dataSet nwi: dataset1; nw: empleado? emp ;
{
apellido? lName.
? mes qb4o: inLevel nw: mes.
}
AGRUPAR POR? FName? LName? Mes
}
skos del mes: trimestre más amplio.

}
AGRUPAR POR? FName? LName?
YearNo ORDER BY? FName?
LName? YearNo
En la consulta anterior, la consulta interna calcula el monto total de ventas

por empleado y mes. La consulta externa acumula el resultado anterior al
nivel de año mientras calcula las ventas anuales totales y las ventas
mensuales promedio.
Consulta 14.9. Monto total de ventas y monto total de descuento por
producto y mes.
SELECT? ProdName? YearNo? MonthNo (SUM (? Sales) AS?
TotalSales) (SUM (? UnitPrice *? Qty *? Disc) AS?
TotalDiscAmount)
¿DÓNDE? O qb: dataSet nwi: dataset1; nw: producto?
{
prod; nw: OrderDate? odate; nw: SalesAmount?
ventas ;
nw: ¿Cantidad? Cant. nw: disco de descuento; nw: UnitPrice? unitPrice.
? mes qb4o: inLevel nw: mes; nw: monthNumber? monthNo; skos:
un cuarto más amplio.
}
AGRUPAR POR? ProdName? AñoNo? MesNo
ORDENAR POR? ProdName? AñoNo? MesNo
En esta consulta, subimos al nivel de mes y luego calculamos las medidas

solicitadas.
Consulta 14.10. Ventas mensuales hasta la fecha para cada categoría de

producto.
SELECCIONAR? CatName? YearNo? MonthNo (SUM (? TotalSales1) AS?
YTDSales) WHERE? Cat qb4o: inLevel nw: Categoría; nw:
{
categoryName? catName.
SELECCIONAR? CatName? YearNo? MonthNo1 (SUM (? Sales1) AS ?
{
totalSales1) DONDE? o1 qb: dataSet nwi: dataset1; nw: Producto?
{
prod1 ;
nw: OrderDate? odate1; nw: SalesAmount? sales1.
? prod1 qb4o: inLevel nw: Producto; skos: más amplio? cat1.
? cat1 qb4o: inLevel nw: Categoría; nw: categoryName? catName.
? year1 qb4o: inLevel nw: Año; nw: año? año No.
}
AGRUPAR POR? CatName? YearNo? MonthNo1
}
}
14.5 Consultar el cubo Northwind en SPARQL
FILTER (? MonthNo >=? mesNo1)
5
AGRUPAR POR? CatName? YearNo?
MonthNo ORDER BY? CatName? YearNo?
MonthNo
Esta consulta comienza seleccionando los niveles de categoría, mes y año.

Luego, para cada categoría, mes y año, la consulta selecciona todos los
hechos cuya fecha de pedido sea del mismo año pero cuyo mes sea menor o
igual que el mes actual.
Consulta 14.11. Media móvil de los últimos 3 meses del importe de las
ventas por categoría de producto.
SELECCIONAR? CatName? YearNo? MonthNo (AVG (? TotalSales1) AS ?
MovAvgSales) DONDE? Gato qb4o: inLevel nw: Categoría; nw:
{
categoryName? catName.
?año qb4o: inLevel nw: Año; nw: año? año No.
OPCIONAL
{
SELECCIONAR? CatName? YearNo1? MonthNo1 (SUM (? Sales1) AS ?
{
totalSales1) DONDE? o1 qb: dataSet nwi: dataset1; nw: Producto? prod1
{
;
nw: OrderDate? odate1; nw: SalesAmount? sales1.
? prod1 qb4o: inLevel nw: Producto; skos: más amplio? cat1.
? cat1 qb4o: inLevel nw: Categoría; nw: categoryName? catName.
}
AGRUPAR POR? CatName? YearNo1? MonthNo1
}
FILTRO (((? MesNo >= 3 &&? YearNo =? YearNo1 &&
? mes No >=? monthNo1 &&? monthNo-2 <=? monthNo1)
|
(? monthNo = 2 && ((? yearNo =? yearNo1 &&? monthNo1 <= 2)
|
(? YearNo =? YearNo1 + 1 &&? MonthNo1 = 12)))
|
(? monthNo = 1 && ((? yearNo =? yearNo1 &&? monthNo1 = 1)
|
(? yearNo =? yearNo1 + 1 &&? monthNo1 >= 11)))))
}
AGRUPAR POR? CatName? YearNo?
MonthNo ORDER BY? CatName? YearNo?
MonthNo
Esta consulta comienza seleccionando los niveles de categoría, mes y año.

Luego, para cada categoría, mes y año, la consulta selecciona todos los
hechos cuya fecha de pedido se encuentra dentro de una ventana de 3
meses desde el mes actual. Esta selección implica una condición elaborada
en la cláusula FILTER, que cubre tres casos, dependiendo de si el mes es
marzo o posterior, el mes es febrero o el mes es enero.
Consulta 14.12. Monto de las ventas personales realizadas por un
empleado en comparación con el monto total de las ventas realizadas por
ella y sus subordinados durante 1997.
SELECCIONAR? FName? LName? PersSales? SubordSales
¿DÓNDE? Emp qb4o: inLevel nw: Empleado; nw:
{
firstName? fName; nw: apellido? lName.
SELECT? Emp (SUM (? Ventas) AS? PersSales)
{
DONDE? O qb: dataSet nwi: dataset1; nw: empleado?
{
emp; nw: OrderDate? odate; nw: SalesAmount?
ventas.
FILTRO (? YearNo = 1997)
}
AGRUPAR POR? Emp
}
SELECCIONAR? Emp (SUMA (? Ventas1)
{
COMO ? subordSales) DONDE? subord nw:
{
supervisor *? emp .
? o1 qb: conjunto de datos nwi: conjunto de datos1;
nw: ¿Empleado? subordinado; nw: OrderDate?
odate1; nw: SalesAmount? ventas.
? mes1 qb4o: inLevel nw: mes; skos: más amplio? trimestre1.
FILTRO (? AñoNo1 = 1997)
}
AGRUPAR POR?
}
Emp ORDENAR POR? Emp
La primera consulta interna calcula por empleado las ventas personales en

1997. La segunda consulta interna explota la jerarquía recursiva
Supervisión con una expresión de ruta de propiedad en SPARQL. El
carácter '*' indica que el cierre transitivo de la jerarquía de supervisión
debe tenerse en cuenta para obtener todos los subordinados de un
empleado. Luego, se agregan las ventas en 1997 de todos estos
subordinados.
Consulta 14.13. Importe total de ventas, número de productos y suma de
las cantidades vendidas para cada pedido.
SELECT? OrderNo (SUM (? Sales) AS? TotalSales)
(COUNT (? Prod) AS? NbProducts) (SUM (? Qty) AS?
NbUnits) WHERE? O qb: dataSet nwi: dataset1; nw: orden? orden
{
;
nw: producto? prod; nw: SalesAmount? ventas; nw: Cantidad? cant.
? order qb4o: inLevel nw: Order; nw: orderNo? orderNo.
}
AGRUPAR POR? OrderNo
ORDER BY? OrderNo
En esta consulta, agrupamos las ventas por número de pedido y luego

calculamos las medidas solicitadas.
Consulta 14.14. Para cada mes, número total de pedidos, monto total de
ventas y monto promedio de ventas por pedido.
SELECT? YearNo? MonthNo (COUNT (? OrderNo) AS?
NbOrders) (SUM (? TotalSales) AS? TotalSalesMonth)
(AVG (? TotalSales) AS? AvgSalesOrder)
DÓNDE
{
SELECT? OrderNo? Odate (SUM (? Sales) AS?
{
TotalSales) WHERE? O qb: dataSet nwi: dataset1; nw:
{
Orden ?pedido ;
? order qb4o: inLevel nw: Order; nw: orderNo? orderNo.}
AGRUPAR POR? OrderNo? Odate }
14.6 Resumen 573

}
GRUPO POR? AñoNo? MesNo
PEDIDO POR? AñoNo?
MesNo
Aquí, la consulta interna calcula las ventas totales por pedido. La consulta
externa luego acumula el resultado anterior al nivel del mes y calcula las
medidas solicitadas.
Consulta 14.15. Para cada empleado, monto total de ventas, número de
ciudades y número de estados a los que está asignada.
SELECT? FName? LName (SUM (? Sales) / COUNT (DISTINCT? City) AS?
TotalSales) (COUNT (DISTINCT? City) AS? NoCities)
(COUNT (DISTINCT? State) AS? NoStates)
¿DÓNDE? O qb: dataSet nwi: dataset1; nw: empleado? emp; nw: SalesAmount? ventas
{
.
apellido? lName; skos: ¿más amplia? ciudad.
? estado qb4o: inLevel nw: estado.
}
AGRUPAR POR? FName?
LName ORDER BY?
FName? LName
Recuerde que existe una relación de muchos a muchos entre los empleados
y las ciudades. Por lo tanto, la consulta anterior se acumula en los niveles
de ciudad y estado y luego agrupa el resultado por empleado. Luego, en la
cláusula SELECT, sumamos la medida del monto de las ventas y la
dividimos por el número de ciudades distintas asignadas a un empleado.
Esto resuelve el problema de la doble contabilización al que nos referimos
en la Sec.4.2.6.
14.6 Resumen
En este capítulo, estudiamos cómo se pueden aplicar las técnicas OLAP en

la web semántica. Primero introdujimos los conceptos principales de RDF
y RDFS, los lenguajes utilizados para representar datos y metadatos en la
web semántica, y SPARQL, el lenguaje estándar para consultar dichos
datos. Luego, estudiamos cómo representar datos relacionales en RDF.
Luego mostramos cómo las técnicas OLAP se pueden aplicar directamente
a conjuntos de datos RDF sin la necesidad de transformar primero los
datos de la web semántica en cubos de datos OLAP. Para ello, necesitamos
vocabularios que nos permitan representar datos y metadatos OLAP.
Estudiamos y comparamos dos de estos vocabularios: el vocabulario del
cubo de datos (QB) y el vocabulario QB4OLAP. Estudiamos las
limitaciones del primero al intentar de fi nir las operaciones OLAP y
mostramos, en base a una porción de un
estudio de caso del mundo real, cómo se pueden implementar estas

operaciones en SPARQL. Finalmente, aplicamos QB4OLAP al cubo de
datos Northwind y consultamos el cubo RDF resultante usando SPARQL.
Hay muchos libros que explican los conceptos básicos de la web semántica,
por ejemplo, [82]. Un libro completamente dedicado a SPARQL es [41]. En
el momento de escribir este libro, no hay mucho trabajo sobre el tema de la
aplicación de OLAP directamente sobre datos RDF. Sección14.3 de este
capítulo se basa en el trabajo de investigación de Etcheverry y Vaisman
sobre QB4OLAP [52, 53]. Kämpgen y Harth [99] También proponen
aplicar operaciones OLAP sobre QB, aunque este enfoque no resuelve las
limitaciones discutidas en este capítulo con respecto a la ausencia de
estructura de dimensiones en QB. En una secuela [100], los mismos
autores propusieron cargar datos estadísticos vinculados en un triple
almacén RDF y responder consultas OLAP utilizando SPARQL. Para ello,
implementan un motor OLAP a SPARQL que traduce las consultas OLAP a
SPARQL.
Nosotros También mencionó que otro enfoque de investigación estudia
cómo extraer datos multidimensionales de la web semántica y luego
analizar estos datos utilizando técnicas OLAP tradicionales. Los métodos
para hacer esto se basan en ontologías, que nos permiten extraer datos de
forma semiautomática. La idea es utilizar ontologías para identificar
hechos y dimensiones que pueden poblar un cubo de datos. A continuación
mencionamos brevemente algunos de estos trabajos.
Niinimäki u n D n ort e iemi [145] t u se ontología mapp En g t o convertir
Data fuentes a RDF y luego consultar estos datos RDF con SPARQL para
completar el esquema OLAP. El proceso ETL está guiado por la ontología.
Además, los autores crean una ontología OLAP, de alguna manera similar a
los vocabularios discutidos en este capítulo. Las ontologías se expresan en
RDF y OWL. En la misma línea, Romero y Abelló [180]abordar el diseño
del almacén de datos a partir de una ontología OWL que describe las
fuentes de datos. Identifican las dimensiones que caracterizan un concepto
central bajo análisis (el concepto de hecho) buscando conceptos conectados
a él a través de relaciones de uno a muchos. La misma idea se utiliza para
descubrir los diferentes niveles de las jerarquías dimensionales, partiendo
del concepto que representa el nivel base. La salida del método es un
esquema de estrella o copo de nieve que garantiza la resumibilidad de los
datos, aptos para ser instanciados en una base de datos multidimensional
tradicional. Finalmente, Nebot y Berlanga [142] propuso un método
semiautomático para extraer datos semánticos bajo demanda en una base
de datos multidimensional. De esta forma, los datos podrían analizarse
utilizando técnicas OLAP tradicionales. Aquí, los autores asumen que los
datos se representan como una ontología OWL. Una parte de esta ontología
contiene los axiomas de la ontología de dominio y aplicación, mientras que
la otra parte contiene el almacén de instancias real. Un esquema
multidimensional debe primero ser
14.9 Ejercicios 575
creado a partir de los requisitos y los conocimientos que se pueden inferir

de las ontologías. A continuación, este esquema se completa
semiautomáticamente a partir de la ontología.
14.8 Revisión Preguntas
14.1 ¿Cuáles son los dos enfoques principales para realizar análisis
OLAP con datos de web semántica?
14.2 Describa brevemente RDF y RDFS y sus principales construcciones.
14.3 Dé un ejemplo de las serializaciones RDF / XML y Turtle de datos
RDF.
14.4 ¿Qué es SPARQL? ¿En qué se diferencia su semántica de la de SQL?
14.5 Dé un ejemplo de una consulta SPARQL, describa sus elementos y
analice cómo se evaluará.
14.6 Explique los dos enfoques estándar para representar datos
relacionales en RDF. ¿En qué se diferencian entre sí?
14.7 ¿Cómo podemos representar datos multidimensionales en RDF?
14.8 Explica brevemente el vocabulario del cubo de datos QB.
14.9 ¿Cómo se pueden representar las jerarquías en QB?
14.10 ¿Es posible realizar una operación de acumulación de datos
representados en QB?
14.11 ¿Cómo supera el vocabulario QB4OLAP las limitaciones anteriores?
14.12 Analizar y discutir la implementación de roll-up en QB4OLAP.
14.13 Explique cómo realizar consultas OLAP en SPARQL.
14.9 Ejercicios
14.1 Dado el cubo de datos Northwind, muestre la representación QB del

Hecho de ventas. Proporcione al menos dos observaciones.
14.2 Dado el cubo de datos Northwind, muestre la representación
QB4OLAP de la dimensión Cliente.
14.3 Haz lo mismo que Ex. 14,2 para la dimensión Empleado.
14.4 Escribir el mapeo R2RML que representa el almacén de datos de
Northwind utilizando el vocabulario QB4OLAP.
14.5 Muestre la consulta SPARQL implementando la operación
ROLLUP (Northwind, Producto → Categoría, SUM (SalesAmount)).
14.6 Muestre la consulta SPARQL implementando la operación

SLICE (Northwind, Cliente, Ciudad ='París').
Ventas
ID del identifi Identificaci ID de ID de ventas en costo de las ventas
Producto cación ón del promoción tienda la tienda la tienda de
de cliente unidades
tiempo
219 738 567 0 1 7.16 2.4344 3
684 738 567 0 1 12,88 5.0232 2
551 739 639 7 2 5,20 2.236 4
Producto
ID del nombre del producto nombre de ID de clase de
Producto la marca producto
219 Chips de maíz de la Mejor 12
mejor elección elección
551 Patatas fritas rápidas Rápido 12
bajas en grasa
684 Yogur de arándanos Gorila 6
gorila
Clase de
producto
ID de clase de subcategoría de categoria de departamento de familia de
producto producto producto producto productos
6 Yogur Lácteos Lácteos Comida
12 Papas Meriendas Meriendas Comida
fritas
Tiempo a dia
identifica la fecha El dia el mes el año dia del mes semana del mes del año trimest
ción de año re
tiempo
738 1998-01-07 miércoles enero 1998 7 4 1 Q1
739 1998-01-08 jueves enero 1998 8 4 1 Q1
Cliente
marital anual
identifi fname mi lname ciuda Expr país estado ingreso género educación
cación d esar
de
cliente
567 Charles L. Christensen Santa Fe DF México S $ 50K- $ F Solteros
639 Miguel J. Troyer Kirkland Was EE.U METRO 70K METR Escuela
hing U $ 30K- $ O secundaria
ton 50K
Promoción
identifi nombre del baile tipo de medio
cación
del
baile
0 Sin promoción Sin multimedia
7 Descuentos Periódico dominical,
fantásticos Radio, TV
Tienda
ID de tipo de nombre de ciudad de estado de país de la tienda
tienda tienda la tienda la tienda la tienda tienda sqft
1 Supermercad Tienda 1 Acapulco Guerrero México 23593
2 o Tienda 2 Bellingham Washing EE.UU 28206
Pequeña ton
tienda de
comestibles
Figura 14.9 Una instancia del almacén de datos de Foodmart
14.7 Represente el esquema del cubo de Foodmart utilizando el vocabulario

QB4OLAP.
14.8 Considere las instancias de la mesa Foodmart dadas en la Fig.
14,9una. Represente los hechos de ventas como observaciones,
siguiendo la definición de estructura de datos especificada en el
ejercicio anterior.
14.9 Escribir en SPARQL las consultas sobre el cubo Foodmart dadas en Ex.
4.9.
Capítulo 15
Conclusión
En este libro, proporcionamos una cobertura en profundidad de los temas

más relevantes en el diseño e implementación de almacenamiento de
datos. Aunque en los Capítulos.11-14 Cubrimos desarrollos avanzados y
muy recientes, hay muchos otros importantes que se han dejado de lado
conscientemente por razones espaciales en favor de tecnologías maduras.
Concluimos este libro con algunos breves comentarios sobre estos temas,
que creemos serán cada vez más relevantes en un futuro próximo. Nos
referimos a un libro reciente [144] donde se pueden encontrar más
perspectivas sobre inteligencia empresarial.
15,1 Temporal Almacenes de datos
La definición clásica de Inmon de almacenes de datos, presentada en la

Sect. 1.1, menciona sus características no volátiles y variables en el tiempo.
Sin embargo, en los almacenes de datos tradicionales, estas características
se aplican solo a las medidas, no a las dimensiones. De hecho, aunque los
almacenes de datos incluyen una dimensión de tiempo que se usa para la
agregación (usando la operación de acumulación) o para filtrar (usando las
operaciones de corte y dados), la dimensión de tiempo no puede usarse
para realizar un seguimiento de los cambios en otras dimensiones, por
ejemplo, cuando un producto cambia de categoría. Esta situación deja a la
capa de aplicación la responsabilidad de representar cambios en las
dimensiones. Los almacenes de datos temporales tienen como objetivo
resolver este problema ampliando los lenguajes de definición y
manipulación de datos con semántica temporal. En un almacén de datos
temporal, los cambios pueden ocurrir en
el nivel de instancia (como en el ejemplo del producto que cambia su
categoría mencionado anteriormente) o en un nivel de esquema, por
ejemplo, cuando se agrega o elimina un nivel de dimensión. Además,
cuando se agrega el nivel inferior de una dimensión o
eliminado, la tabla de hechos asociada se ve afectada y su esquema debe
modificarse. Todos estos cambios deben ser manejados automáticamente
por el lenguaje de definición de datos. La semántica del lenguaje de
consulta también debe tener en cuenta estos cambios para producir las
agregaciones correctas.
54655-6 15,
5 15
Los almacenes de datos temporales tienen como objetivo aplicar los

resultados de muchos años de investigación en bases de datos temporales
al campo del almacén de datos. Las bases de datos temporales
proporcionan estructuras y mecanismos para representar y administrar
información que varía con el tiempo. En resumen, las bases de datos
temporales permiten almacenar datos pasados o futuros en una base de
datos, así como los instantes de tiempo en que ocurrieron o ocurrirán los
cambios en estos datos. Así, las bases de datos temporales permiten a los
usuarios conocer la evolución de la información necesaria para resolver
problemas complejos en muchos dominios de aplicación en los que el
tiempo está presente de forma natural, por ejemplo, aplicaciones de
gestión de tierras, financieras y sanitarias.
Los almacenes de datos temporales plantean muchos problemas, incluida la
agregación consistente en presencia de datos variables en el tiempo,
consultas temporales, métodos de almacenamiento y materialización de la
vista temporal. Además, la comunidad de investigadores ha prestado muy
poca atención al modelado conceptual y lógico de los almacenes de datos
temporales o al análisis del soporte temporal que debería incluirse en los
almacenes de datos. Algunas de estas cuestiones se han abordado en la
bibliografía en diversos grados.
Golfarelli y Rizzi proporcionan una encuesta de almacenes de datos
temporales [66]. Con un enfoque en el modelado conceptual de almacenes
de datos temporales, Malinowski y Zimanyi [124, 127] introdujo datos
variables en el tiempo (es decir, temporales)
tipos para mantener el historial de las dimensiones del almacén de datos y
extendió el modelo MultiDim estudiado en este libro para abordar los
almacenes de datos temporales. Además, las reglas de traducción de lo
conceptual a lo relacional y objetual
se dan modelos relacionales. También se han propuesto modelos de datos
lógicos
para almacenes de datos temporales [42-44, 136, 137]. Por ejemplo,
Mendelzon y
Vaisman [136, 137] introdujo TOLAP, un modelo de datos y lenguaje de
consulta en el que el esquema y las instancias de las relaciones entre los
niveles en una jerarquía tienen una marca de tiempo con sus intervalos de
validez. Estas marcas de tiempo definen cómo se agregan los miembros a
nivel de dimensión. De esta manera, podemos agregar medidas según el
esquema de dimensión y las instancias que existían cuando ocurrieron los
hechos correspondientes.
Vale la pena señalar que las dimensiones que cambian lentamente,
estudiadas en el Cap. 5, abordan el problema anterior de manera limitada y
son solo una variante de los almacenes de datos temporales. Además, las
soluciones de dimensiones que cambian lentamente no tienen en cuenta
toda la investigación que se ha realizado en el campo de las bases de datos
temporales. Hemos visto que algunas de las soluciones para dimensiones
que cambian lentamente no conservan la historia completa de los datos y
son difíciles de implementar. Una de las principales diferencias entre los
modelos temporales discutidos anteriormente y el enfoque de dimensiones
que cambian lentamente es que este último ignora la semántica de las
actualizaciones de las jerarquías de dimensiones. Por lo tanto, la ruta
válida en un determinado instante en una jerarquía temporal debe
calcularse manualmente en el momento de escribir la consulta en lugar de
ser contabilizada automáticamente por el lenguaje de la consulta.
Otro enfoque para el almacenamiento de datos temporales es el de
múltiples versiones. Por ejemplo, Ravat et al. [170] definió un modelo
multidimensional multiversión que consiste en un conjunto de versiones
estrella, cada una asociada con un temporal
15.2
5 Almacenes de datos espaciales 3D / 4D 15 579
intervalo e incluyendo una versión para un hecho y una versión para cada
dimensión asociada con un hecho. Siempre que se produzcan cambios en
las dimensiones o los hechos a nivel de esquema, se crea una nueva versión
estrella. Wrembel y Bebel adoptaron un enfoque similar [230], donde cada
cambio en el esquema o en el nivel de instancia da como resultado la
creación de una nueva versión del esquema, aunque esa versión tenga la
misma estructura que la original en el caso de cambios en el nivel de
instancia. Otras propuestas sobre este tema son, por ejemplo, [31, 140,
208, 231]. La sutil interrelación entre los almacenes de datos temporales y
la multiversión aún debe investigarse. Por ejemplo, una actualización del
esquema de una tabla de origen puede desencadenar un cambio en el
esquema del almacén de datos, por lo que se crea una nueva versión del
almacén de datos. Sin embargo, no sería confiable crear una nueva versión
del almacén de datos cada vez que cambia una instancia. Para ello, marcar
con el tiempo la asociación entre niveles sería claramente una mejor
opción. Por otro lado, si la fuente de datos fuera una base de datos
temporal, un almacén de datos temporal que contabilice, por ejemplo, los
cambios de esquema y parece natural.
A pesar de los avances en el campo, las bases de datos temporales no se
han
adoptado por los profesionales de la base de datos y, como consecuencia, lo
mismo ocurre en el campo del almacén de datos. Ésta es la razón principal
por la que no incluimos los almacenes de datos temporales en este libro.
Sin embargo, vale la pena señalar que la última versión del estándar SQL
lanzada en 2011 tiene facilidades temporales. Además, los sistemas de
administración de bases de datos actuales como Oracle, Teradata y DB2
también brindan soporte temporal. La disponibilidad de tales
características implica que los sistemas de almacenamiento de datos
temporales se convertirán en una realidad en un futuro cercano, pero para
que eso suceda, las bases de datos temporales deben usarse más de lo que
lo han sido hasta ahora.
15.2 Almacenes de datos espaciales 3D / 4D
En nuestro estudio de almacenes de datos espaciales y espacio-temporales

(Cap. 11 y 12), no habíamos abordado su extensión para gestionar objetos
tridimensionales y tetradimensionales (3D / 4D), lo que conduciría a
almacenes de datos espaciales 3D / 4D.
Muchas aplicaciones modernas requieren la integración de datos
espaciales 2D y 3D (consulte una revisión completa en [20]). Por ejemplo,
aplicaciones como la gestión de instalaciones y la gestión de desastres en
las ciudades no solo requieren información sobre las ubicaciones, sino
también información sobre el interior de los edificios. En levantamientos
catastrales y seguros, el volumen de un edificio también puede ser de
interés. A pesar de la necesidad de tal integración entre los mundos 2D y
3D, típicamente el mundo 2D se representa digitalmente como un mapa y
el mundo 3D como un modelo 3D, ambos implementados en modelos de
datos completamente diferentes y mínimamente integrados. Sin embargo,
nada debe impedir
5 15
integre un mapa de ciudad en 2D con un modelo de ciudad en 3D en una

base de datos espacial utilizando un enfoque de modelado unificado.
Más, En los últimos años, hemos sido testigos de un creciente interés en
los sistemas de bases de datos espaciales 4D (es decir, 3D más tiempo). Por
ejemplo, existe una necesidad urgente de pasar de los antiguos sistemas
catastrales 2D a los 4D [40]. El modelado climático y la prevención de
desastres son otras aplicaciones que dependen del modelado 4D. En la
mayoría de los casos, es posible pasar de un modelo 3D a uno 2D, pero
pasar de 2D a 3D o 4D no lo es. Por tanto, el geomodelado 3D es un área de
investigación que se requiere con urgencia para producir nuevos sistemas
de geoinformación 3D / 4D. Además, el diseño e implementación de
operaciones de bases de datos geométricas y topológicas para mover
objetos 3D (es decir, 4D) es un foco de interés para la investigación y la
industria. Aunque en la literatura se han propuesto varios modelos
conceptuales que soportan objetos 3D considerando tanto aspectos
geométricos como topológicos (p. Ej., [106, 112, 241]), ningún sistema de
gestión de bases de datos actual admite modelos topológicos 3D, aunque
muchos admiten topologías 2D. Una necesidad clave para esto consiste en
desarrollar índices espaciales para modelos topológicos. En resumen, las
direcciones en este campo son la integración perfecta entre los modelos de
datos 2D y 3D para que sean utilizables en ambos mundos y el desarrollo
de sistemas de información geográfica 3D / 4D. Un paso en esta dirección
es CityGML,1 un modelo de información abierto para representar,
almacenar e intercambiar modelos de ciudades y paisajes en 3D. CityGML
se implementa como un esquema de aplicación para Geography Markup
Language (GML) [110], el estándar para el intercambio de datos espaciales
emitido por el Consorcio Geoespacial Abierto, y proporciona un estándar
para describir la geometría, topología y semántica de objetos 3D. CityGML
es altamente escalable y admite no solo edificios, sino también sitios
completos, distritos, ciudades, regiones y países. CityGML proporciona
contenido en 3D, lo que permite la visualización a través de varias
aplicaciones, pero también permite a los usuarios compartir modelos
virtuales de ciudades y paisajes en 3D para análisis sofisticados, por
ejemplo, simulaciones ambientales, análisis de demanda de energía,
gestión de ciudades y gestión de desastres. Como ejemplo, la aplicación de
CityGML a un estudio de caso en los Países Bajos se puede encontrar en
[216]. Hay una serie de conferencias dedicadas específicamente a la
GeoInformación 3D. Los volúmenes de estas conferencias son publicados
por Springer,
siendo el último [165].
Dada la discusión anterior, el lector en este punto no debería
sorprenderse al saber que muy pocas publicaciones han abordado la
combinación de almacenes de datos y objetos 3D. Como ejemplo, el
almacén de datos de BioMap [121, 122] integra fuentes de datos biológicos
para proporcionar recursos integrados de secuencia / estructura / función
que apoyan el análisis, la minería y la visualización de datos genómicos
funcionales. La extensión de los modelos conceptuales para el
almacenamiento de datos en esta dirección requiere en primer lugar la
definición de 3D espacial.
http://www.citygml.org/
1
15.3 Texto Almacenes de datos analíticos y de texto 581
5 15
tipos de datos, operadores topológicos 3D y operaciones y funciones

espaciales que pueden operar en tipos de datos 3D. Después de eso, deben
abordarse cuestiones como la agregación de medidas espaciales. Por lo
tanto, existe un terreno fértil para la investigación en el campo de los
almacenes de datos espaciales 3D. Combinando estos con almacenes de
datos de trayectoria como los que estudiamos en el Cap.12 conduciría a
almacenes de datos espaciales 4D.
Otro tema importante a este respecto es hacer frente a múltiples
representaciones de datos espaciales, lo que significa permitir que el
mismo objeto del mundo real tenga varias geometrías. Tratar con múltiples
representaciones es un requisito común en las bases de datos espaciales, en
particular como consecuencia de tratar con múltiples niveles de resolución
espacial. Este también es un aspecto importante en los almacenes de datos,
ya que los datos espaciales pueden integrarse desde sistemas de origen que
contienen datos en varias resoluciones espaciales diferentes. En este libro,
hemos asumido implícitamente que hemos seleccionado una
representación de las disponibles. Sin embargo, es posible que necesitemos
admitir múltiples representaciones en un modelo multidimensional.
Nuevamente, los modelos conceptuales deben extenderse para permitir
múltiples representaciones de datos espaciales, como es el caso del modelo
espacio-temporal MADS [155]. Sin embargo, esto plantea algunos
problemas importantes. Por ejemplo, si los niveles que forman una
jerarquía pueden tener múltiples representaciones, se necesitan
condiciones adicionales para establecer operaciones significativas de
acumulación y desglose.
15.3 Texto Almacenes de datos analíticos y de texto
Otros temas que prevemos que serán importantes en el futuro son el

análisis de texto y los almacenes de datos de texto. Esto se desprende
claramente de las estadísticas que informan que solo el 20% de los datos
corporativos están en sistemas transaccionales y el 80% restante en otros
formatos, principalmente texto [171, 206]. Además, el advenimiento de las
redes sociales ha producido enormes cantidades de datos de texto y las
herramientas estudiadas en el Cap.13 tengo hizo posible el análisis de estos
datos. Los almacenes de datos de texto pueden ayudar a realizar esta tarea,
como explicamos a continuación.
La extracción automática de información estructurada del texto se ha
estudiado durante mucho tiempo. Hay dos enfoques principales para la
extracción de información: el enfoque de aprendizaje automático y el
basado en reglas. La mayoría de los sistemas de ambas categorías se
crearon para que los especialistas los utilicen en entornos académicos y, en
general, no son escalables para grandes cargas de trabajo.
En el enfoque de aprendizaje automático, técnicas como las estudiadas
en el Cap. 9 son usados. Por ejemplo, la clasificación automática de texto se
ha abordado extensamente utilizando principalmente técnicas de
aprendizaje supervisado, en las que se asignan etiquetas de categoría
predefinidas a los documentos. Algunos ejemplos son el algoritmo de
Rocchio, el vecino k más cercano, los árboles de decisión, el algoritmo
ingenuo de Bayes, las redes neuronales y las máquinas de vectores de
soporte, entre otros. Más
5 15
recientemente, cada vez se utiliza más la combinación de diferentes

métodos de aprendizaje. Se puede encontrar un resumen de estas técnicas
en [54].
Un ejemplo de un sistema de extracción de información basado en
reglas es SystemT-IE [107,172], resultado de una investigación llevada a
cabo en el IBM Almaden Research Center. Este sistema ahora se incluye
como parte del conjunto de productos de InfoSphere BigInsights. SystemT-
IE viene con un lenguaje declarativo similar a SQL denominado
Annotation Query Language (AQL) [30] para especificar programas de
extracción de análisis de texto (llamados extractores) con semántica de
reglas. Los extractores obtienen información estructurada a partir de texto
no estructurado o semiestructurado. Para esto, AQL extiende SQL con la
declaración EXTRACT. Los datos en AQL se almacenan en relaciones
donde todas las tuplas tienen el mismo esquema, análogo a las tablas
relacionales de SQL. Además, AQL incluye declaraciones para crear tablas,
vistas, funciones definidas por el usuario y diccionarios. Sin embargo, AQL
no admite funciones SQL avanzadas como subconsultas correlacionadas y
consultas recursivas. Una vez generados los extractores, un optimizador
produce un plan de ejecución eficiente para ellos en forma de un gráfico de
operador de anotación. Finalmente, el plan se ejecuta mediante un motor
en tiempo de ejecución, que aprovecha las arquitecturas paralelas.
Las técnicas de extracción de información como la que se presentó
anteriormente se pueden usar para poblar un almacén de datos para el
análisis de texto multidimensional usando OLAP. Normalmente, un
proceso ETL extraerá datos textuales de varias fuentes y, después de la
limpieza y transformación, cargará dichos datos en el almacén. Las fases de
este proceso incluirán la extracción de datos textuales y metadatos de los
documentos; transformación de los datos extraídos a través de técnicas
clásicas de recuperación de texto como limpieza de textos, derivación,
ponderación de términos, modelado de lenguaje, etc. y cargar los datos
resultantes de la fase de transformación en el almacén de datos. En un
libro reciente [92], WH Inmon detalla, a un alto nivel de abstracción, las
tareas que debe realizar un proceso ETL para almacenes de datos de texto.
A continuación, analizamos algunas propuestas en el campo de los
almacenes de datos de texto.
En una de las primeras obras en el campo, Tseng y Chou [206]
proponen un almacén de documentos para el análisis multidimensional de
datos textuales. Su enfoque consiste en combinar el procesamiento de texto
con el procesamiento OLAP numérico. Para ello, organizan documentos no
estructurados en datos estructurados que constan de dimensiones,
jerarquías, hechos y medidas. Las dimensiones se componen de una
jerarquía de palabras clave que hacen referencia a un concepto, que se
obtienen mediante herramientas de minería de texto. Los hechos incluyen
los identificadores de los documentos bajo análisis y el número de veces
que aparece una combinación de palabras clave en dichos documentos. Por
ejemplo, supongamos que estamos analizando documentos para descubrir
productos y ciudades que aparecen juntos. Una jerarquía de palabras clave
que hacen referencia a productos se puede representar en una dimensión
de producto con un esquema (ProductKey, Keyword, KeywordLevel,
Parent), donde ProductKey es la clave sustituta de la palabra clave,
15.4 Almacenes de datos 5
KeywordLevel. Por ejemplo, una jerarquía de palabras clave como TV→
Aparato
5 15
Todos los productos se pueden representar mediante tuplas (p1, Todos

→
los productos, 1, 1), (p2, Aparato, 2, 1) y (p3, TV, 3, 2). La última tupla
dice, por ejemplo, que la palabra clave TV pertenece al nivel de jerarquía 3
y su padre está en el nivel 2. Dimension City sería análoga y podría
contener, por ejemplo, una tupla (c4, Bruselas, 3, 2). La tabla de hechos
está compuesta por las claves de las dimensiones Producto y Ciudad, el
identi fi cador de un documento que contiene una combinación de un
producto y una ciudad, y el número de veces que esta combinación
aparece en el documento. Por ejemplo, una tupla en la tabla de hechos
puede ser (p3, c4, d1, 3), que indica que la combinación de palabras
clave TV y Bruselas aparece tres veces en el documento d1. Sobre esta
estructura, las operaciones OLAP se pueden realizar como de costumbre.
En [117], Lin et al. presentan la noción de Text Cube, un cubo de datos
para datos textuales, mientras que en [39] Ding y col. estudiar el problema
de las palabras clave
búsqueda de top-k en cubos de texto, es decir, dada una consulta de
palabra clave, encuentra las celdas más relevantes de top-k en un cubo de
texto. El cubo de texto contiene tanto información estructural (es decir,
dimensiones convencionales) como información textual. Por lo tanto, un
cubo de texto es un cubo de datos OLAP tradicional ampliado para resumir
y navegar por datos de texto estructurados y no estructurados. Una celda
en el cubo de texto agrega un conjunto de documentos que contienen una
combinación de palabras clave y valores de atributos en las dimensiones
del cubo. Por ejemplo, supongamos que queremos analizar reseñas de
modelos de televisión. Podemos diseñar un cubo de texto con esquema
(Marca, Modelo, Precio, Revisión), donde los tres primeros atributos son
dimensiones y el último es la medida que representa la revisión.
documentos. Considere tres celdas en el cubo, a saber, c1: (Sony, S1, 400,
{d1}), c2: (Sony, S2, 800, {d2}) y c3: (Panasonic, P1, 400, {d3} ). Además,
suponga que los documentos d1, d2 y d3 contienen las palabras clave light,
cheap, modern, { }
costoso, moderno y barato, duradero, respectivamente. Si un usuario
{} { }
desea encontrar las celdas del cubo que son más relevantes para las
palabras clave baratas y duraderas, la respuesta seráC3 ya que la revisió n incluye los dos
términos. Las células también se pueden agregar. Por ejemplo, celdas C1 y C3 arriba tienen como celda principal ( ,, 400,
d1, d2), que contiene las reseñas agregadas por precio. Las celdas
∗∗ { }
agregadas también se pueden incluir en la respuesta a una consulta
analizando las palabras clave presentes en la unión de los documentos.
Existen otros enfoques en líneas similares, como los de Zhang et al.
[237, 238], donde los autores introducen la noción de Topic Cube, que
combina OLAP con un modelo temático probabilístico. Omitimos la
descripción de
estas propuestas aquí.
15.4 Almacenes de datos multimedia
Los tipos de datos nuevos y complejos plantean nuevos desafíos para el

análisis de datos. Por ejemplo, nos gustaría realizar operaciones OLAP
sobre datos de imagen o música y, en general, sobre datos multimedia.
Para esto, multimedia
5 15
almacenes de datos debe diseñarse de manera similar a los almacenes

de datos tradicionales. Las posibles dimensiones de los datos de imagen y
video pueden ser el tamaño de la imagen o el video, el ancho y alto de los
fotogramas, la fecha de creación, etc. Muchas de estas dimensiones
también se aplican a otros tipos de datos multimedia.
El principal problema de los almacenes de datos multimedia es su alta
dimensionalidad. Esto se debe al hecho de que los objetos multimedia,
como las imágenes, se representan en una base de datos mediante
descriptores, que pueden ser de dos tipos: descriptores basados en
contenido (o características) y descriptores basados en descripciones (o
textuales). Los primeros representan el contenido intrínseco de los datos
(como el color, la textura o la forma). Estos últimos representan datos
alfanuméricos como fecha de adquisición, autor, tema, etc. La mayoría de
los descriptores basados en contenido están orientados a conjuntos y no a
un solo valor. Esto tendría como consecuencia, por ejemplo, que
podríamos necesitar definir cada color diferente como una dimensión.
Dado este escenario de alta dimensión, el principal desafío es poder
realizar análisis multimedia en un tiempo de ejecución razonable.
Image OLAP tiene como objetivo apoyar el análisis multidimensional en
línea de datos de imágenes. Un ejemplo de los esfuerzos en este campo es
el trabajo de Jin et al. [97], quien propuso Visual Cube para realizar OLAP
multidimensional en
colecciones de imágenes, como imágenes web indexadas por motores de
búsqueda, productos
imágenes (por ejemplo, de tiendas en línea) y fotos compartidas en las
redes sociales. Visual Cube define dos tipos de dimensiones: dimensiones
de metainformación como fecha, título, nombre de archivo, propietario,
URL, etiqueta, descripción y ubicación GPS y dimensiones visuales
(basadas en las características visuales de la imagen) como tamaño de la
imagen, colores principales, dimensión de la cara (que indica la existencia
de caras) y un histograma de color / textura. Para resolver el problema de
dimensionalidad comentado anteriormente, los autores proponen dos tipos
de esquemas, a saber, un esquema multidimensional (MDS) y un esquema
unidimensional (SDS). En una representación MDS, cada valor posible de
una característica se considera una dimensión. Por ejemplo, Sunny puede
ser una dimensión. Cada registro correspondiente a una imagen de un día
soleado contendrá un '1' en esta dimensión. Por otro lado, en una
representación SDS, las muchas características posibles serán
reemplazadas por una dimensión denominada Etiqueta. Por lo tanto, una
imagen de un día soleado contendrá el valor soleado en la dimensión
Etiqueta. Además, un atributo de valor establecido contendrá los
identificadores de las imágenes con esa característica, y un atributo de
valor único contendrá el número total de dichos identificadores. Las
medidas en Visual Cube pueden ser una imagen representativa en un grupo
o el número de elementos en dicho grupo. Los conglomerados se calculan
mediante técnicas como las estudiadas en el capítulo. Las medidas en
Visual Cube pueden ser una imagen representativa en un grupo o el
número de elementos en dicho grupo. Los conglomerados se calculan
mediante técnicas como las estudiadas en el capítulo. Las medidas en
Visual Cube pueden ser una imagen representativa en un grupo o el
número de elementos en dicho grupo. Los conglomerados se calculan
mediante técnicas como las estudiadas en el capítulo.9. Los registros de un
grupo tienen una combinación de descriptores que corresponden a las
dimensiones del cubo. De esta forma, se pueden realizar operaciones
OLAP. Por ejemplo, se puede realizar un desglose haciendo clic en una
imagen para encontrar otras en el clúster. Las preguntas abiertas son, por
ejemplo, una evaluación eficiente de las k consultas principales (dada una
celda de consulta, encuentre las k celdas similares superiores medidas por
la similitud
5 15
de sus imágenes) y actualización incremental de Visual Cube (dadas nuevas

imágenes, actualice eficientemente el cubo).
En el campo médico (como también es el caso, por ejemplo, en
bioinformática), los datos multimedia constituyen información valiosa
para el proceso de toma de decisiones. Arigon y col. [8, 9] han aplicado la
idea de almacenes de datos multimedia para analizar electrocardiogramas
(ECG). Este trabajo tiene como objetivo ampliar los sistemas de apoyo a las
decisiones clínicas con información multimedia. Este requisito plantea
muchos desafíos. Por un lado, se necesitan funciones de modelado
avanzadas como las que se estudian en este libro. Los ejemplos incluyen el
apoyo de jerarquías complejas (una patología puede pertenecer a muchas
clases), relaciones de muchos a muchos (un paciente puede tener muchas
patologías y viceversa), etc. Por otro lado, se deben admitir datos
multimedia complejos y probablemente también datos textuales. Para
manejar estos datos, los primeros usuarios deben desarrollar algoritmos
eficientes (por ejemplo, basados en el procesamiento de señales o
imágenes, reconocimiento de patrones, metodologías estadísticas, entre
otros) para transformar los datos en bruto iniciales (por ejemplo, un ECG o
una radiografía) en descriptores de datos. Seleccionar un conjunto
apropiado de descriptores es un desafío y depende del dominio bajo
análisis. En el trabajo que estamos comentando, los autores utilizan los
esquemas de estrella y copo de nieve como herramientas de modelado. En
estos esquemas, las dimensiones son los descriptores de estos datos. Hay
tres dimensiones relacionadas con el paciente: patología principal, edad y
sexo (descriptores basados en descripciones) y dos dimensiones
relacionadas con la adquisición del ECG: tiempo y tecnología. Finalmente,
dos dimensiones están relacionadas con el contenido de los ECG: la
duración del QT (el tiempo después de la repolarización de los ventrículos)
y el nivel de ruido (descriptores basados en el contenido). La tabla de
hechos está compuesta por la clave externa de dichos descriptores y la
señal de ECG. Así, podemos, por ejemplo, contar el número de ECG que
tienen unas características determinadas, o calcular un promedio sobre
una lista de ECG que tienen determinadas características para obtener un
"ECG medio". Tenga en cuenta la similitud con el enfoque de Visual Cube
descrito anteriormente.
De manera similar, los almacenes de datos musicales están comenzando a
atraer
atención de los investigadores y de la industria, que surge del interés en la
llamada recuperación de información musical. El trabajo de Deliège y
Pedersen [37, 38] prevé una extensión de las tecnologías de
almacenamiento de datos a los almacenes de música que integran una gran
variedad de información relacionada con la música, incluidas funciones de
bajo nivel e información musical de alto nivel. Los autores definen un
almacén de música como un almacén de datos dedicado optimizado para
almacenar y analizar contenido musical. El trabajo analiza las
características que debe soportar un almacén de música y las dimensiones
que debe contener un cubo de música, incluyendo una clasificación de
metadatos de música en cuatro categorías: (a) editorial, que cubre
información administrativa e histórica; (b) cultural, de fi nido como
conocimiento producido por el medio (como reseñas, por ejemplo); (c)
acústico, que se refiere a características acústicas, como análisis espectral,
o wavelets, que describen el contenido musical; y (d) físico, que se refiere al
medio de almacenamiento.
5 15
Hay muchos problemas abiertos que resolver para hacer realidad los
almacenes de música. Además, todavía no existe un modelo de datos claro
ni un lenguaje de consulta. Finalmente, los autores identifican diez
desafíos para los almacenes de música. Algunos de ellos son la definición
de funciones de agregación apropiadas para datos acústicos, recuperación
consciente de la precisión, soporte de varios tipos de jerarquías e
integración de nuevos tipos de datos. Como puede verse, la mayoría de los
problemas ya resueltos en los data warehouses tradicionales siguen
abiertos en el ámbito musical, abriendo así un interesante campo de
investigación para los próximos años.
15.5 Análisis de gráficos y almacenes de datos de

gráficos
Análisis de gráficos ha ido ganando impulso de forma constante en la

comunidad de gestión de datos en los últimos años, ya que muchas
aplicaciones del mundo real se modelan naturalmente como gráficos, en
particular en el dominio del análisis de redes sociales. Un sistema de
gestión de bases de datos de gráficos [178] es un sistema de administración
de bases de datos que permite crear, leer, actualizar y eliminar un modelo
de datos de gráficos. Algunos sistemas utilizan almacenamiento de gráficos
nativo, lo que significa que están optimizados y diseñados para almacenar
y administrar estructuras de datos de gráficos. Otros serializan los datos
del gráfico en una base de datos relacional o relacional de objetos. Las
bases de datos de gráficos brindan un mejor soporte para la gestión de
datos de gráficos que las bases de datos relacionales. Esto se debe
principalmente al hecho de que las bases de datos relacionales tratan
implícitamente los datos conectados, mientras que las bases de datos de
gráficos almacenan gráficos reales. Bases de datos de gráficos
representativos como Neo4J2 y titán3 tengo su propio modelo de datos.
También tienen su propio lenguaje de consulta, llamado Cypher y Gremlin,
respectivamente.
Dado el amplio uso de gráficos para representar problemas prácticos, el
análisis multidimensional de datos de gráficos y los almacenes de datos de
gráficos son campos prometedores para la investigación y el desarrollo de
aplicaciones. Es necesario realizar análisis de gráficos desde diferentes
perspectivas y con múltiples granularidades. Esto plantea nuevos desafíos
a la tecnología OLAP tradicional.
Los gráficos cuyos nodos son del mismo tipo se denominan homogéneos.
Los gráficos heterogéneos, por otro lado, pueden tener nodos de diferentes
tipos. A continuación comentamos algunas propuestas basadas en gráficos
homogéneos desde
trabajar en gráficos heterogéneos (p. ej., [235]) se encuentra en una etapa
preliminar.
En [28, 29]. Este marco, llamado Graph OLAP, presenta una vista
multidimensional y multinivel de gráficos. Como ejemplo, considere un
conjunto de autores
trabajar en un campo determinado, digamos almacenes de datos. Si dos
personas fueron coautoras
X documentos en una conferencia, digamos DaWaK 2009, luego se agrega
un enlace entre
http://www.neo4j.org/
2
http://thinkaurelius.github.io/titan/
3
15.5 Análisis de gráficos y almacenes de datos de gráficos 587
5 15
ellos, que tiene un atributo de frecuencia de colaboración x. Para cada

conferencia de cada año, es posible que tengamos un gráfico de coautor
que describa los patrones de colaboración entre los investigadores. Por lo
tanto, cada gráfico se puede ver como una instantánea de la red de
colaboración general. Estos gráficos se pueden agregar en un estilo OLAP.
Por ejemplo, podemos agregar gráficos para obtener colaboraciones por
tipo de conferencia y año para todas las parejas de autores. Para esto,
debemos agregar los nodos y los bordes en cada gráfico de instantánea de
acuerdo con el tipo de conferencia (como conferencias de base de datos) y
el año. Por ejemplo, si hay un vínculo entre dos autores en las conferencias
SIGMOD y VLDB, los nodos y el borde estarán en el gráfico agregado
correspondiente al tipo de conferencia Bases de datos. Se pueden obtener
patrones más complejos, por ejemplo,
Tomando Teniendo en cuenta los conceptos anteriores, en Graph OLAP,
las dimensiones se clasifican en informativas y topológicas. Los primeros
están cerca de las jerarquías de dimensión OLAP tradicionales utilizando
información de la instantánea
niveles, por ejemplo, Conference Field All. Se pueden usar para agregar y
organizar instantáneas como se→explicó anteriormente. Por otro lado, las
dimensiones topológicas se pueden utilizar para operar en nodos y bordes
dentro de redes individuales. Por ejemplo, una jerarquía de autores como
AuthorId Institution pertenecerá a una dimensión topológica→ya que las
instituciones de autor no definen instantáneas. Estas de fi niciones
producen dos tipos diferentes de operaciones Graph OLAP. Un roll-up
sobre una dimensión informativa superpone y une instantáneas (pero no
cambia los objetos), mientras que un roll-up sobre una dimensión
topológica fusiona nodos en una instantánea, modificando su estructura.
Cubo de gráfico [239] es un modelo para almacenes de datos gráficos que
admite
Consultas OLAP en grandes redes multidimensionales, teniendo en cuenta
tanto
agregación de atributos y resumen de la estructura de las redes. Una red
multidimensional consiste en una colección de vértices, cada uno de los
cuales contiene un conjunto de atributos multidimensionales que
describen las propiedades de los nodos. Por ejemplo, en una red social, los
nodos pueden representar personas y los atributos multidimensionales
pueden incluir ID de usuario, Género, Ciudad, etc. Por lo tanto, los
atributos multidimensionales en los vértices del gráfico definen las
dimensiones del cubo del gráfico. Las medidas son gráficos agregados
resumidos de acuerdo con algunos criterios. Tenga en cuenta que el
problema aquí es diferente al Graph OLAP, donde hay varias instantáneas.
En Graph Cube, solo tenemos una red grande, por lo que tenemos un
problema de resumen de gráficos. Por ejemplo, supongamos que tenemos
una pequeña red social con tres nodos. Dos de ellos corresponden a
individuos masculinos de la red, mientras que el tercero corresponde a una
mujer. Un gráfico que resume las conexiones entre géneros tendrá dos
nodos, uno etiquetado como masculino y el otro etiquetado como
femenino. Los bordes entre ellos se anotarán con el número de conexiones
de algún tipo. Por ejemplo, si en el gráfico original había dos conexiones
entre dos personas masculinas (en ambos
5 15
direcciones), el gráfico resumido contendrá un ciclo sobre el nodo

masculino, anotado con un '2'. Si solo hubiera una conexión entre una
mujer y un hombre, habrá una ventaja entre los nodos masculino y
femenino anotado con un '1'.
Tenga en cuenta que desde el punto de vista del modelado, no hay
acuerdo sobre un modelo conceptual para bases de datos gráficas. Para
llenar este vacío, en [62] los autores introducen un modelo conceptual para
bases de datos de gráficos, orientado a permitir a los analistas realizar
análisis de datos sobre gráficos no solo en un estilo OLAP, sino también
utilizando análisis más sofisticados como la minería de datos, por ejemplo.
Para ello, como es habitual, se deben de fi nir medidas y dimensiones. Los
autores identificaron dos tipos de medidas: medidas informativas, que se
calculan a partir de los atributos de los bordes y nodos, y medidas
estructurales, que resultan de los algoritmos realizados sobre las
propiedades estructurales del gráfico. Una medida estructural podría ser,
por ejemplo, un subgrafo que contenga el camino más corto entre dos
nodos o un valor numérico que calcule la longitud del camino. La evolución
de los gráficos es fundamental para este modelo. Esto permitiría, por
ejemplo,
Apéndice A
Notación gráfica
A continuación, resumimos la notación gráfica utilizada en este libro.
A.1 Relación entre entidades Modelo
Cliente
nombre
Tipo de
entidad
(descripción
breve)
atrib Cliente
dentificación del cliente Nombre (1,1) Apellido Fecha de nacimiento Salario Rango No Niños (0,1) Profesión (1, n) Dirección
Calle de ciudad uto de
Aficiones (0, n) Nombre Rangoidentificador de cardinalidad predeterminada
nombre
simple monovaluado
atributos cardinalidades
atributo compuesto
de atributo atributo compuesto
multivalor multivalor
atributos de los componentes
atributos de los
componentes
Tipo de
entidad
(con atributos e identificadores mostrados)
Tipo de entidad
Sección
débil (descripción
breve)

sistemas y aplicaciones centrados en datos, DOI 10.1007 / 978-3-642- 5-6,
5 15
© Springer-Verlag Berlín Heidelberg 2014 589

5 Una notación gráfica
Sección
Semestre Año
Página de inicio (0,1)
Tipo de entidad débil

(con atributos e identificadores parciales
mostrados) cardinalidades
(0, n) (1, n)
Participar
nombre
Tipo de relación
(descripción
breve)
cardinalidad
es
(0, n) (1, n)
Participar
atrib
StartDate EndDate Salario
utos de
nombre
Tipo de relación (con

atributos mostrados)
(0, n) (1, n)
CouSec
Identificación del tipo de

relación (descripción breve)
(0, n) (1, n)
CouSec
Año del semestre
Identificación del tipo de

relación (con los atributos
mostrados)
Cliente
Identificación del cliente Nombre del cliente CustomerAddress BranchName

supertipo
Persona subtipos Empresa

ProfessionName ClassName Escribe un nombre SectorName
Tipo de relación de
generalización /
especialización
A.3 Modelo MultiDim para almacenes de 5
A.2 Modelo relacional
nom Producto
bre atributo ProductKey ProductNumber ProductName Descripción
de clave
primaria
atributos
clave alternativa AK:

Tabla relacional
(con atributos y claves mostrados)
Categoría
atributo de Producto
CategoryKey atributo de
clave
ProductKey clave
primari Categoría
Número de primaria
a producto Nombre
Nombre del Descripción
producto
atributo de Descripción
clave Integridad
externa
referencial
atributos
nomb Product
re atributo o atributo de
Product Número nombre Descripción Clave de clave
de clave o de del catego
primaria Clave product produc ría externa
o to
1 QB876 Leche ... C1 instancias
Tabla relacional con instancias
A.3 Modelo MultiDim para almacenes de datos
nombre Producto
Nivel
(Breve
Producto
descripción)
atrib
uto de Número de producto ProductName Descripción Tamaño
identificador de
nombre
atributos descriptivos
Nivel
Ventas
nombre
Hecho
(Breve descripción)
Ventas
medi
Cantidad Cantidad
das de nombre
Hecho
(con las medidas mostradas)
(0,1)
(1,1)
(0, n)
(1, n)
Cardinalidades
Cliente Dimensión muchos a

uno
Identificación del cliente Nombre de empresa
...
Dimensión
de juego de Dimensión de
roles muchos a muchos
Hora Ventas SalesReason
Fecha de
Fecha de vencimiento
orden SalesReasonId SalesReasonDesc
Cantidad Cantidad
...
Fecha
DayNbWeek
...
Pedido
Doce y cincuenta y nueve de la noche
dimensión
N º de pedido
Dirección de
entrega
Tipos de dimensiones
nivel de
hoja nivel de raíz
criterio cardinalidad
es
Producto
Grupos de
Categoría Departamento
Número de
producto Nombre de la categoría Descripción
Nombre de Departamento Descripción
ProductName
Descripción
Tamaño
nivel padre
nivel
infantil jerarquía equilibrada
A.3 Modelo MultiDim para almacenes de 5
miembro de la hoja miembro dedepartamento A

nivel de la raíz nivel
Categoría 1 categoría 2
producto A producto B producto C producto D

Miembros de la jerarquía
Rama Banc
Cajero automático Agencia o
BranchName Nombre del
ATMNumber Modelo de dirección
Nombre de agencia Habla a NoEmpleados
Estruc
banco
... ... Habla a Habla a
Capital Sede
... ...
Jerarquía desequilibrada
Empleado
ID de empleado Nombre Apellido

...
Supervi
Supervisión
Subordinar
Jerarquía de padres e hijos
terrible nivel Sector nivel de ingreso

SectorName Descripción
Cliente ... Rama
CustTy
Identificación del BranchName

cliente Descripción
CustomerName Profesión ...
Dirección
ProfessionName Descripción
...
camino exclusivo camino simbólico exclusivo símbolo
Jerarquía generalizada
Región
Expresar País
RegionName Código de región
...
Subdivisi
Nombre del Estado Código del estado Capital del estado Nombre del país Población de capital
... ...
Jerarquía irregular
atributo de distribución
Empleado porcentaje ÷ Sección
OrgStuct
ID de empleado Nombre de empleado
... Nombre de sección Descripción
...
Jerarquía no estricta
Trimes
tre Año fiscal
fiscal
Hora Trimestre No Año fiscal
Mes ... ...
Ho
Fecha
MonthName
... ... Trimestre
calendar Año del
io calendario
Trimestre No Año del
... calendario
...
Jerarquía alternativa
Ciuda Expre
d sar
Cliente Nombre de la Nombre del
ciudad Estado
Viv
Ciudad Capital del

Identificación del cliente Nombre Apellido
Población Fecha de nacimiento Dirección
estado
... Área urbana Estado
Población
Grupo
... de edad ...
AgeGroupId Descripción
E
Jerarquías independientes paralelas
Ciudad
Nombre de la ciudad Ciudad Población Ciudad Área

Empleado ...
Expresar
Viv
ID de empleado Nombre Apellido Título Fecha de nacimiento

Nombre del Estado Estado Capital Estado Pobla
... ...
Territorio
Territori
TerritoryName Descripción
Jerarquías dependientes paralelas

A.4 Modelo MultiDim para almacenes de datos 5
Hora Venta
s
Fecha Día Cantidad
Nombre Unidad Producto
Semana Precio
ID del Producto Producto Nombre Cantida
Semana Nb Ventas
Año Monto
Expre País
Ciudad sar
Geografí
Nombre del Nombre del

Nombre de la ciudad Altitud de Estado
la población país País
EnglishStateName Código País
StateCode Capital
Hecho con múltiples granularidades
A.4 Modelo MultiDim para almacenes de datos

espaciales
tipo de datos
nombre espaciales para el
Expresar
nivel
Nivel espacial
(breve
descripción)
atrib tipo de datos
Expresar
espaciales para
uto de
el Población
Nombre del Estado Estado nivel Estado Área Estado Mayor Capita
identificador de
nombre
atributos tipo de datos

espaciales para
temáticos Nivel atributo
espacial
atributo
espacial
relación
topológica
condado
Expresar
Ubicación
Jerarquía
CountyName Condado espacial
Población Condado Área
Nombre
del Estado
Mantenimi Estado Capital
nombre ento de de la población
carreteras relación
topológica
Hecho
espacial (breve
descripción)
nombre Mantenimien
to de relación
medida carreteras
calculada con topológica
operadores
espaciales Hecho espacial tipo de datos
Longitud espaciales para
medida (con las medidas
CommonAr medir
espacial mostradas)
A.5 Notación BPMN para 5
A.5 Notación BPMN para ETL
Carga de producto
Actividad
Flujo de secuencia ConditionalDefault secuencia de secuencia flujo de flujo
Flujo de mensajesAsociación Conectando objetos

Continente País Estado
Carga
+
Carga del estado del país del continente
Carga continente Carga del país Carga de estado
Subproceso
Bucle
Actividad Subproceso
+
Bucle
ExclusivoInclusivo Paralelo Complejo

Tipos de pasarelas
Terrible Fusión
Dividir y fusionar pasarelas
Iniciar evento Intermedio Evento final

evento
Hora Mensaje Compensación Cancel Terminar

ar
Tipos de
eventos
Actividad Actividad
Cancela Compensado
do Enviar Corregi
mensaje r error
Actividades canceladas y compensadas
Datos de
entrada Datos de Datos de Insertar datos
entrada entrada
Archivo: Base de datos: Viento Base de datos: Viento Archivo: BadCities.txt

Time.xls del norte del norte Tipo: Texto
Tipo: Mesa: Clientes Consulta: <Consulta Opciones: Encabezados, vacíos
Sobresalir SQL>
Insertar
datos Actualizar DataDelete Datos Añadir columna
Base de datos: Base de datos: Columna: SalesAmount =

Base de datos:
NorthwindDW NorthwindDW D.UnitPrice * (1-Discount) *
NorthwindDW
Mesa: Hora Mesa: Columnas de Cantidad
Mesa: Producto
Asignaciones: producto: Para = Dónde: ProductKey
TimeKey-> OrderDateKey Ahora () Dónde: Coincidencias:
Opciones: Adjuntar ProductKey Coincide ProductKey
con: ProductKey
Columna de
Añadir Column Column caída
columna a de a de
actualiz actualiz
Columna: Base de datos ación ación Columna: Imagen
de carga: NorthwindDW
Consulta: <Consulta SQL> Columna: Base de datos
Columna: Descripción
= Recortar de carga: NortwhindDW Eliminar
Cambiar (Descripción) Consulta: <consulta SQL>
duplicados
nombre de
columna Agregado
Convert
ir
Columna: Región-> column Agrupar por: N º de pedido
Estado a Columnas: Cnt = Count (*),
TotalSales = Sum
(SalesAmount)
Columnas:
Fecha: Fecha Día Nb
Semana: Smallint
Clasificar Multidifusión
Columnas: Aporte: EmployeeKey,

OrderDate, Amount DESC CityKey Salida *:
EmployeeKey, CityKey
Tareas de datos unarios

Unión Diferencia Entrar
Aporte*: CityName,
Aporte*: CityName, StateKey, CountryKey StateKey,
Salida: CityName, Condición:
CountryKey
StateKey, EmployeeID
Salida:
CountryKey = EmployeeKey
CityName,
Mantener StateKey, Tipo
No de combinación: Unión
CountryKey
duplicados:
Buscar Buscar Buscar Buscar
Recuperar:
Recuperar: CountryKey Base de datos: StateKey Base
NorthwindDW Tabla:dePaís
datos: NorthwindDW
Dónde:
Reemplazar: Query:
Coincidencias
CountryKey State
Base Join
de países: deReemplazar:
Country
CountryName
datos: Donde:
StateKey
State,
NorthwindDW Base
Country
dePaís
Tabla: datos:
Coincide:
NorthwindDW
Dónde: StateNa
Coinciden
Tareas de datos n-arios
Recuperar: CountryKey Base de datos: NorthwindDW Tabla: País Dónde:

Recuperar:
Coincidencias
CountryKey
de países:
BaseCountryName
de datos: NorthwindDW Tabla: País Dónde: C
Condición: ¿Encontró?
Y Encontró
Buscar norte Buscar
Extraviado
Notación taquigráfica para búsqueda

Referencias
1. A.Abelló, J. Samos, F. Saltor, YAM2 (Yet Another Multidimensional Model): una

extensión de UML. Inf. Syst. 32 (6), 541–567 (2006)
2. S. Agarwal, R. Agrawal, P. Deshpande, A. Gupta, JF Naughton, R.
Ramakrishnan, S. Sarawagi, Sobre el cálculo de agregados multidimensionales,
en Actas de la 22a Conferencia Internacional sobre Bases de Datos Muy
Grandes, VLDB '96 (Morgan Kaufmann, 1996), págs. 506–521
3. R. Agrawal, R. Srikant, Algoritmos rápidos para reglas de asociación minera en
grandes bases de datos, en Actas de la 20ª Conferencia Internacional sobre Bases
de Datos Muy Grandes, VLDB'94 (Morgan Kaufmann, 1994), págs. 487–499
4. R. Agrawal, R. Srikant, Mining secuencial de patrones, en Actas de la 11th
International Conference on Data Engineering, ICDE'95 (IEEE Computer Society
Press, 1995), págs. 3-14
5. A Ahmed, M. Miquel, Estructuras multidimensionales dedicadas a fenómenos
espacio-temporales continuos, en Actas de la 22ª Conferencia Nacional Británica
sobre Bases de Datos, BNCOD 2005. Lecture Notes on Computer Science, vol. 3567
(Springer, 2005), págs. 29–40
6. A Ahmed, M. Miquel, R. Laurini, Apoyando la toma de decisiones para los
fenómenos espacio-temporales, en Actas de la 3ra Conferencia Internacional sobre
Tecnología de la Información: Investigación y Educación, ITRE, 2005, págs. 440–
444
7. G. Andrienko, N. Andrienko, Un marco general para usar la agregación en la
exploración visual de datos de movimiento. Cartográfico J. 47 (1), 22–40
(2010)
8. A. Arigon, A. Tchounikine, M. Miquel, Manejo de múltiples puntos de vista en
un almacén de datos multimedia. ACM Trans. Computación multimedia.
Comun. Apl. 2 (3), 199–218 (2006)
9. A. Arigon, A. Tchounikine, M. Miquel, Almacenes de datos multimedia: un
modelo de múltiples versiones y una aplicación médica. Aplicación de
herramientas multimedia 35 (1), 91 a 108 (2007)
10. WD Back, N. Goodman, J. Hyde, Mondrian en acción: análisis empresarial de
código abierto (Manning Publications Co., 2013)
11. Y. Serdard S. Rivest, METRO. Proulx, Espacial o nline aanalítico Procesando
(SOLAP): conceptos, arquitecturas y soluciones desde la perspectiva de la
ingeniería geomática, en Data Warehouses y OLAP: Conceptos, Arquitecturas y
Soluciones, ed. por
R. Wrembel, C. Koncilia (IRM Press, 2007), capítulo 13, págs. 298–319
12. L. Bellatreche, M. Schneider, H. Lorinquer, MK Mohania, Reuniendo
particiones, vistas materializadas e índices para optimizar el rendimiento de los
almacenes de datos relacionales, en Actas de la 6a Conferencia Internacional
sobre
54655-6,
6 Referenc
Almacenamiento de datos y descubrimiento de conocimientos, DaWaK'04. Notas

de la conferencia en Ciencias de la Computación, vol. 3181 (Springer, 2004), págs.
15-25
13. S. Bimonte, M. Miquel, Cuando el análisis espacial se encuentra con OLAP: modelo
multidimensional y operadores. En t. J. Data Warehouse Mining 6 (4), 33–60
(2010)
14. S. Bimonte, M. Bertolotto, J. Gensel, O. Boussaid, OLAP espacial y
generalización de mapas: modelo y álgebra. En t. J. Data Warehouse Mining 8
(1), 24–51 (2012)
15. METRO. Bo¨ hnlein, A. U lbrich-vom Ende, D er viviendo inicial datos
me rcan cí a casas estructuras de los modelos de datos conceptuales de los sistemas
de información operativos subyacentes, en Actas del 2do Taller internacional de
ACM sobre almacenamiento de datos y OLAP, DOLAP'99 (ACM, 1999), págs. 15-21
16. A. Bonifati, F. Cattaneo, S. Ceri, A. Fuggetta, S. Paraboschi, Designing data
marts for data warehouse. ACM Trans. Ing. De software Methodol. 10 (4), 452–
483 (2001)
17. G. Booch, I. Jacobson, J. Rumbaugh, El lenguaje de modelado unificado: Guía
del usuario, 2ª ed. (Addison-Wesley, 2005)
18. R. Bouman, J. van Dongen, Pentaho Solutions: Business Intelligence y Data
Warehousing con Pentaho y MySQL (Wiley, 2009)
19. J. Bowen, Introducción a Talend Open Studio para la integración de datos
(Packt Publishing, 2012)
20. M. Breunig, S. Zlatanova, investigación de bases de datos geográficas 3D:
direcciones retrospectivas y futuras. Computación. Geociencias 37 (7), 791–803
(2011)
21. RM Bruckner, B. List, J. Schiefer, Luchando hacia la integración de datos casi en
tiempo real para almacenes de datos, en Actas de la 4ª Conferencia Internacional
sobre Almacenamiento de Datos y Descubrimiento del Conocimiento, DaWaK'02.
Notas de la conferencia en Ciencias de la Computación, vol. 2454 (Springer, 2002),
págs. 317–326
22. L. Cabibbo, R. Torlone, Consultando bases de datos multidimensionales, en Actas
del 6º Taller internacional sobre lenguajes de programación de bases de datos.
págs. 319–335
23. L. Cabibbo, R. Torlone, Un enfoque lógico para las bases de datos
multidimensionales, en Actas de la 6ª Conferencia Internacional sobre la
ampliación de la tecnología de bases de datos, EDBT'98. Notas de la conferencia en
Ciencias de la Computación, vol. 1377 (Springer, 1998), págs. 183–197
24. GRAMO. Câmara, D. Palomo, RCM de Souza, F. de Oliveira, O. Regina, Hacia un
álgebra de mapas generalizada: principios y tipos de datos, en Actas del VII
Simposio Brasileño de Geoinformática, GeoInfo 2005 (2005), págs. 66–81
25. E. Capriolo, D. Wampler, J. Rutherglen, Programming Hive (O'Reilly Media,
2012)
26. M. Casters, R. Bouman, J. van Dongen, Pentaho Kettle Solutions: Creación de
soluciones ETL de código abierto con integración de datos de Pentaho (Wiley,
2010)
27. J. Celko. Analytics y OLAP en SQL (Morgan Kaufmann, 2006)
28. C. Chen, X. Yan, F. Zhu, J. Han, PS Yu, Graph OLAP: hacia el procesamiento
analítico en línea en gráficos, en Proceedings of the 8th IEEE International
Conference on Data Mining, ICDM 2008 (IEEE Computer Society Press, 2008 ),
págs. 103-112
29. C. Chen, X. Yan, F. Zhu, J. Han, PS Yu, Graph OLAP: un marco multidimensional
para el análisis de datos de gráficos. Knowledge Inf. Syst. 21 (1), 41 a 63 (2009)
30. L. Chiticariu, R. Krishnamurthy, Y. Li, S. Raghavan, F. Reiss, S. Vaithyanathan,
SystemT: un enfoque algebraico para la extracción de información declarativa,
en Actas de la 48a Reunión Anual de la Asociación de Lingüística
Computacional, ACL 2010 (Asociación de Lingüística Informática, 2010), págs.
128-137
31. J. Chmiel, T. Morzy, R. Wrembel, Índice de unión de múltiples versiones para
Referenc 6
almacenamiento de datos de múltiples versiones. Inf. Software Technol. 51 (1),
98 a 108 (2009)
6 Referenc
32. C. Ciferri, R. Ciferri, LI Go´mez, METRO. Schneider,AA Vaisman, E. Zimányi,

Álgebra de cubos: un modelo genérico centrado en el usuario y un lenguaje de
consulta para cubos OLAP. En t.
J. Data Warehousing Mining 9 (2), 39–65 (2013)
33. J. Cohen, B. Dolan, M. Dunlap, JM Hellerstein, C. Welton, habilidades MAD:
nuevas prácticas de análisis para big data. Proc. Dotación de VLDB 2 (2), 1481–
1492 (2009)
34. J.PAG. Cordeiro, G. Câmara, UF Moura, CC Barbosa, F. Almeida, Formalismo
algebraico sobre mapas, en Actas del VII Simposio Brasileño de Geoinformática,
GeoInfo 2005 (2005), págs. 49–65
35. L. Davidson, JM Moss, Pro SQL Server 2012 Diseño e implementación de bases de
datos relacionales. (APress, 2012)
36. J. Dean, S. Ghemawat, MapReduce: una herramienta de procesamiento de datos
flexible. Comun. ACM 53 (1), 72–77 (2010)
37. F. Delawareliège, T .B. Educación física dersen, Música mercancíacasas:
Cdesafíos por tél Siguiente generación de los motores de búsqueda de música, en
Actas del primer taller internacional sobre el aprendizaje de la semántica de las
señales de audio, LSAS 2006, 1996, págs. 95–105
38. F. Delawareliège, T .B. Educación física dersen, Fuzzy canción conjuntos por
metro usic mercancíacasas en Proceegolpes de la 8va Conferencia
Internacional sobre Recuperación de Información Musical, ISMIR 2007
(Sociedad Austriaca de Informática, 2007), págs. 21-26
39. B. Ding, B. Zhao, CX Lin, J. Han, C. Zhai, AN Srivastava, NC Oza, Búsqueda
eficiente basada en palabras clave para las celdas top-k en el cubo de texto.
IEEE Trans. Knowledge Data Eng. 23 (12), 1795-1810 (2011)
40. F.Döner, R. Thompson, J. Stoter, Cap. Lemmen, P. van Oosterom, H. Ploeger,
S. Zlatanova, Soluciones para catastro 4D - con un caso de estudio sobre redes
de servicios públicos. En t. J. Inf. Geográfica. Sci. 25 (7), 1173–1189 (2011)
41. B. DuCharme, Learning SPARQL: Consultando y actualizando con SPARQL 1.1,
2nd edn. (O'Reilly Media, 2013)
42. J. Eder, C. Koncilia, Cambios de datos de dimensión en almacenes de datos
temporales, en Actas de la 3ª Conferencia Internacional sobre Almacenamiento de
Datos y Descubrimiento del Conocimiento, DaWaK'01. Notas de la conferencia en
Ciencias de la Computación, vol. 2114 (Springer, 2001), págs. 284-293
43. J. Eder, C. Koncilia, T. Morzy, El metamodelo COMET para almacenes de datos
temporales, en Actas de la 14ª Conferencia Internacional sobre Ingeniería
Avanzada de Sistemas de Información, CAiSE'02. Notas de la conferencia en
44. J. Eder, K. Wiggisser, Modelado de transformaciones entre versiones de un
almacén de datos temporal, en Proceedings of the ER 2008 Workshops. Notas de la
conferencia en Ciencias de la Computación, vol. 5232 (Springer, 2008), págs. 68–
77
45. Z. El Akkaoui, E. Zimańyi, De fi niendo los flujos de trabajo de ETL usando BPMN
y BPEL, en Actas del 12º Taller internacional de ACM sobre almacenamiento de
datos y OLAP, DOLAP 2009 (ACM, 2009), págs. 41–48
46. Z. El Akk ao ui, MI. Zimanyi, J .-NORTE. Mazoń, J . T r ujillo, A m es del-
impulsado marco para el desarrollo de procesos ETL, en Actas del 14 ° Taller
internacional de ACM sobre almacenamiento de datos y OLAP, DOLAP 2011 (ACM,
2011), págs. 45–52
47. Z.El Akkaoui, J.-N. Mazón, AA Vaisman, E. Zimańyi, Modelado conceptual de
procesos ETL basado en BPMN, en Actas de la 14ª Conferencia Internacional sobre
Almacenamiento de Datos y Descubrimiento del Conocimiento, DaWaK 2012.
Lecture Notes in Computer Science, vol. 7448 (Springer, 2012), págs. 1-14
48. Z. El Akkaoui, MI. Zimanyi, J.-NORTE. Mazón, J. Trujillo, A Basado en
BPMN diseño and marco de mantenimiento para procesos ETL. En t. J. Data
Warehousing Mining 9 (3), 46–72 (2013)
49. R. Elmasri, S. Navathe, Fundamentos de los sistemas de bases de datos, 6ª ed.
(Addison-Wesley, 2011)
Referenc 6
50. N. Enríquez, SS Rathore, Descubrimiento de la inteligencia empresarial
mediante MicroStrategy 9 (Packt Publishing, 2013)
51. M. Ester, H.-P. Kriegel, J. Sander, X. Xu, Un algoritmo basado en densidad para
descubrir clústeres en grandes bases de datos espaciales con ruido, en Actas de la
2da Conferencia Internacional sobre Descubrimiento de Conocimiento y Minería
de Datos, KDD-96 (AAAI Press, 1996), págs. . 226–231
52. L. Etcheverry, AA Vaisman, Mejora del análisis OLAP con cubos web, en Actas
de la 9ª Conferencia de Web Semántica Extendida, ESWC 2012. Lecture Notes
in Computer Science, vol. 7295 (Springer, 2012), págs. 469–483
53. L. Etcheverry, AA Vaisman, QB4OLAP: un vocabulario para cubos OLAP en la
web semántica, en Proceedings of the Third International Workshop on
Consuming Linked Data, COLD 2012. CEUR Workshop Proceedings, vol. 905.
CEUR-WS.org, 2012
54. R. Farkas, Técnicas de aprendizaje automático para la extracción de información
aplicada. Doctor. tesis, Universidad de Szeged, 2009
55. S. Pocos, confusión en el tablero. Intell. Enterprise 7, 14 a 15 (2004)
56. S. Few, Diseño de paneles de información: la comunicación visual efectiva de
datos. (O'Reilly Media, 2006)
57. METRO. García Matt´ıo, DR Bernabeu, Pentaho 5.0 Reporting by Example:
Beginner's Guide (Packt Publishing, 2013)
58. H. García-Molina, JD Ullman, J. Widom, Sistemas de bases de datos: El libro
completo, 2ª ed. (Prentice Hall, 2008)
59. MN Garofalakis, R. Rastogi, K. Shim, SPIRIT: minería secuencial de patrones con
restricciones de expresión regular, en Proceedings of the 25th International
Conference on Very Large Data Bases, VLDB'99 (Morgan Kaufmann, 1999), págs.
223-234
60. MN Garofalakis, R. Rastogi, K. Shim, Minería de patrones secuenciales con
restricciones de expresión regular. IEEE Trans. Knowledge Data Eng. 14 (3),
530–552 (2002)
61. A. Gates, Programming Pig (Medios de O'Reilly, 2011)
62. UNA. Ghrab, S. Skhiri, S. Jouili, MI. Zimányi, Anorte analytics-consciente
coconceptual m es del para gráficos en evolución, en Actas de la 15ª Conferencia
Internacional sobre Almacenamiento de Datos y Descubrimiento del
Conocimiento, DaWaK'13. Lecture Notes in Computer Science (Springer, 2013),
págs. 1–12
63. O. Glorio, J. Trujillo, Un enfoque MDA para el desarrollo de almacenes de datos
espaciales, en Actas de la X Conferencia Internacional sobre Almacenamiento de
Datos y Descubrimiento de Conocimiento, DaWaK'08. Notas de la conferencia en
64. O.Glorio, J.-N. Mazon, I. Garrigós, J. Trujillo, Un proceso de personalización para
el desarrollo de data warehouse espacial. Decis. Soporte Syst. 52 (4), 884–898
(2012)
65. M. Golfarelli, S. Rizzi, Un marco metodológico para el diseño de almacenes de
datos, en Actas del primer taller internacional de ACM sobre almacenamiento de
datos y OLAP, DOLAP'98 (ACM, 1998), págs. 3–9
66. M. Golfarelli, S. Rizzi, Una encuesta sobre almacenamiento de datos temporales.
En t. J. Data Warehouse Mining 5 (1), 1–17 (2009)
67. M. Golfarelli, S. Rizzi, Diseño de almacén de datos: principios y metodologías
modernas (McGraw-Hill, 2009)
68. M. Golfarelli, D. Maio, S. Rizzi, Diseño conceptual de almacenes de datos a partir
de esquemas E / R, en Proceedings of the 31st Hawaii International Conference on
System Sciences, HICSS-31 (IEEE Computer Society Press, 1998), págs. 334 –343
69. LI Go´mez, S. Go´mez, A.A. Virginiaes hombre, A generico datos mesdel
aDakota del Norte query lenguaje para el análisis de cubos OLAP espacio-
temporal, en Actas de la 15ª Conferencia Internacional sobre la ampliación de la
tecnología de bases de datos, EDBT 2012 (ACM, 2012), págs. 300–311
6 Referenc
70. LIGo´mez, B. Kuijpers, B. Moelans, AA Vaisman, Un estado del arte en

almacenamiento de datos espacio-temporales, OLAP y minería, en Integraciones
de almacenamiento de datos, minería de datos y tecnologías de bases de datos:
enfoques innovadores, ed. . por D. Taniar, L. Chen (IGI Global, 2011), capítulo 9,
págs. 200–236
71. I. Gorbach, A. Berger, E. Melomed, Microsoft SQL Server 2008 Analysis
Services Unleashed (Pearson Education, 2009)
72. J. Gray, S. Chaudhuri, A. Basworth, A. Layman, D. Reichart, M. Venkatrao,
F. Pellow, H. Pirahesh, cubo de datos: un operador de agregación relacional
que generaliza agrupaciones, tablas cruzadas y subtotales. Descubrimiento del
conocimiento de minería de datos. 1 (1), 29 a 53 (1997)
73. A. Gupta, IS Mumick, VS Subrahmanian, Manteniendo puntos de vista
incrementalmente, en Actas de la Conferencia Internacional ACM SIGMOD
sobre Gestión de Datos, SIGMOD'93 (ACM, 1993), págs. 157-166
74. A. Gupta, IS Mumick, Mantenimiento de visiones materializadas: problemas,
técnicas y aplicaciones. IEEE Data Eng. Toro. 18 (2), 3 a 18 (1995)
75. R.H. Gu¨ting, M. Schneider, Bases de datos de objetos en movimiento (Morgan
Kaufmann, 2005)
76. J. Han, J. Pei, Y. Yin, Minería de patrones frecuentes sin generación de candidatos,
en Actas de la Conferencia Internacional ACM SIGMOD sobre Gestión de Datos,
SIGMOD'00 (ACM, 2000), págs. 1-12
77. J. Han, M. Kamber, J. Pei, Minería de datos: conceptos y técnicas, 3ª ed.
(Morgan Kaufmann, 2011)
78. V. Harinarayan, A. Rajaraman, JD Ullman, Implementing data cubes
eficientemente, en Proceedings of the 1996 ACM SIGMOD International
Conference on Management of Data (ACM, 1996), págs. 205–216
79. S. Harinath, R. Pihlgren, DG-Y. Lee, J. Sirmon, RM Bruckner, Servicios de
análisis profesionales de Microsoft SQL Server 2012 con MDX y DAX (Wrox,
2012)
80. D. Hecksel, B. Wheeler, P. Boyd-Bowman, J. Testut, D. Gray, C. Dupupet,
Introducción a Oracle Data Integrator 11g: Tutorial práctico (Packt Publishing,
2012)
81. I. Hilgefort, Informes y análisis con SAP BusinessObjects, 2ª ed. (Prensa SAP,
2012)
82. pag. Hitzler, M. Krotzsch, S. Rudolph, Fundamentos de las tecnologías web
semánticas
(Prensa CRC, 2011)
83. C. Howson, E. Newbould, SAP BusinessObjects BI 4.0 La referencia completa,
3ª ed. (McGraw-Hill, 2012)
84. CA Hurtado, C.Gutierrez, Manejo de la heterogeneidad estructural en OLAP, en
Almacenes de datos y OLAP: conceptos, arquitecturas y soluciones, ed. por
R. Wrembel, C. Koncilia (IRM Press, 2007), capítulo 2, págs. 27–57
85. CA Hurtado, C. Gutiérrez, A. Mendelzon, Captura de resumir con restricciones
de integridad en OLAP. ACM Trans. Sistema de base de datos 30 (3), 854–886
(2005)
86. CA Hurtado, A. Mendelzon, Razonamiento sobre la resumibilidad en esquemas
multidimensionales heterogéneos, en Proceedings of the 8th International
Conference on Database Theory, ICDT'01. Notas de la conferencia en Ciencias de la
Computación, vol. 1973 (Springer, 2001), págs. 375–389
87. CA Hurtado, A. Mendelzon, restricciones de dimensión OLAP, en Proceedings
of the 3rd ACM SIGACT-SIGMOD Symposium on Principles of Database
Systems, PODS'02 (ACM, 2002), págs. 375–389
88. B. H u¨ semann,J. Lechtenbörger, G. Vossen, Conceptual data warehouse design,
in Proceedings of the 2nd International Workshop on Design and Management of
Data Warehouses, DMDW'00, CEUR Workshop Proceedings, 2000, p. 6
Referenc 6
89. S. Idreos, F. Gro ff en, N. Nes, S. Manegold, KS Mullender, ML Kersten, MonetDB:
dos décadas de investigación en arquitecturas de bases de datos orientadas a
columnas. IEEE Data Eng. Toro. 35 (1), 40 a 45 (2012)
90. WH Inmon, Construyendo el almacén de datos (Wiley, 2002)
91. WH Inmon, C. Imho ff, R. Sousa, Fábrica de información corporativa, 2ª ed.
(Wiley, 2001)
92. WH Inmon, K. Krishnan, Creación del almacén de datos no estructurados
(Technics Publications, LLC, 2011)
93. ISO TC 211, Información geográfica - Esquema de geometría de cobertura y
funciones: ISO 19123: 2005 (2005)
94. ISO / IEC JTC 1 / SC 32, Tecnología de la información - Lenguajes de base de datos
- Paquetes de aplicaciones y multimedia SQL - Parte 3: Espacial: ISO / IEC 13249-
3: 2011, 4a ed. (2011)
95. H. Jagadish, L. Lakshmanan, D. Srivastava, Qué pueden hacer las jerarquías
para los almacenes de datos, en Actas de la 25ª Conferencia Internacional sobre
Bases de Datos Muy Grandes, VLDB'99 (Morgan Kaufmann, 1999), págs. 530–
541
96. M. Jarke, M. Lanzerini, C. Quix, T. Sellis, P. Vassiliadis, Diseño de almacén de
datos impulsado por la calidad, en Fundamentals of Data Warehouses, 2nd
edn. (Springer, 2003), págs. 165-179
97. X. Jin, J. Han, L. Cao, J. Luo, B. Ding, CX Lin, Visual cube y procesamiento
analítico en línea de imágenes, en Actas de la XIX Conferencia ACM sobre Gestión
de la Información y el Conocimiento, CIKM 2010 ( ACM, 2010), págs. 849–858
98. METRO. Ju¨rgens, E ndex S t ructuras Fo Data Almacenes. Conferencia
Notas en Comcomputadora Science, vol. 1859 (Springer, 2002)
99. B. Kämpgen, A. Harth, Transformación de datos estadísticos vinculados para su
uso en sistemas OLAP, en Actas de la 7ª Conferencia Internacional sobre Sistemas
Semánticos, I-SEMANTICS 2011. (ACM, 2011), págs. 33–40
100. B. Ka¨mpgen, A. Ciervoh, norteo stamaño encaja all: Running tél star Carolina
del Surhema sernchmark wcon SPARQL y vistas agregadas de RDF, en Actas de la
10ª Conferencia Internacional sobre la Web Semántica, ESWC 2013. Lecture Notes
in Computer Science, vol. 7882 (Springer, 2013), págs. 290-304
101. L. Kaufman, PJ Rousseeuw, Finding Groups in Data: An Introduction to
Cluster Analysis (Wiley, 1990)
102. R. Kimball, J. Caserta, The Data Warehouse ETL Toolkit: Técnicas prácticas para
extraer, limpiar, conformar y entregar datos (Wiley, 2004)
103. R. Kimball, M. Ross, The Data Warehouse Toolkit: The Complete Guide to
Dimensional Modeling, 3rd edn. (Wiley, 2013)
104. R. Kimball, L. Reeves, M. Ross, W. Thornthwaite, El kit de herramientas del
ciclo de vida del almacén de datos: métodos expertos para diseñar, desarrollar e
implementar almacenes de datos (Wiley, 1998)
105. B. Knight, E. Veerman, JM Moss, M. Davis, C. Rock, Servicios de integración
profesionales de Microsoft SQL Server 2012 (Wrox, 2012)
106. T. Kolbe, R. Gro¨ger, Towards uni fied 3D city models, en Proceedings of ISPRS
Commission IV Joint Workshop on Challenges in Geospatial Analysis, Integration
and Visualization II, 2003
107. R. Krishnamurthy, Y. Li, S. Raghavan, F. Reiss, S. Vaithyanathan, H. Zhu,
SystemT: un sistema para la extracción de información declarativa. SIGMOD
Rec. 37 (4), 7 a 13 (2008)
108. K. Kulkarni, J.-E. Michels, Características temporales en SQL: 2011. SIGMOD
Rec. 41 (3), 34 a 43 (2012)
109. T. Lahiri, M.-A. Neimat, S. Folkman, Oracle TimesTen: una base de datos en
memoria para aplicaciones empresariales. IEEE Data Eng. Toro. 36 (2), 6 a 13
(2013)
6 Referenc
110. R. Lake, D. Burggraf, M. Trninic, L. Rae, Lenguaje de marcado de geografía:

Fundación para la Geo-Web (Wiley, 2004)
111. A. Lamb, M. Fuller, R. Varadarajan, N. Tran, B. Vandier, L. Doshi, C. Bear, La
base de datos analítica de Vertica: C-Store 7 años después. Proc. VLDB 5 (12),
1790–1801 (2012)
112. S.Larrivée, Y. Bédard, J. Pouliot, Cómo enriquecer la semántica de las bases de
datos geoespaciales expresando correctamente objetos 3D en un modelo
conceptual, en Proceedings of the OTM 2005 Workshops: On the Move to
Meaningful Internet Systems. Notas de la conferencia en Ciencias de la
113. J. Lechtenbörger, GRAMO. Vossenorte, Multidimensional normal formas por
datos mercancíacasa diseño. Inf. Syst. 28 (5), 415–434 (2003)
114. W. Lehner, J. Albrecht, H. Wedekind, Formas normales para bases de datos
multidimensionales, en Actas de la X Conferencia Internacional sobre Gestión de
Bases de Datos Científicas y Estadísticas, SSDBM'98 (IEEE Computer Society
Press, 1998), págs. 63–72
115. H. Lenz, A. Shoshani, Summarizability in OLAP y bases de datos estadísticas,
en Proceedings of the 9th International Conference on Scienti fi c and
Statistical Database Management, SSDBM'97 (IEEE Computer Society Press,
1997), págs. 132–143
116. SS Lightstone, TJ Teorey, T. Nadeau, Diseño de base de datos física: Guía del
profesional de la base de datos para explotar índices, vistas, almacenamiento y
más, 4ª ed. (Morgan Kaufmann, 2007)
117. CX Lin, B. Ding, J. Han, F.Zhu, B. Zhao, Cubo de texto: cálculo de medidas de
infrarrojos para el análisis de bases de datos de texto multidimensionales, en Actas
de la 8a Conferencia Internacional de IEEE sobre Minería de Datos, ICDM 2008
(IEEE Computer Society Press , 2008), págs. 905–910
118. X. Liu, C. Thomsen, TB Pedersen, ETL dimensional basado en MapReduce
simplificado. Proc. Dotación de VLDB 5 (1), 1882–1885 (2012)
119. S. Lujań-Mora, J. Tr ujillo, A comprensivo reuniócapacho por datos
mercancía casa diseño, in Proceedings of the 5th International Workshop on
Design and Management of Data Warehouses, DMDW'03. Actas del taller CEUR,
2003
120. S.Lujań-Mora, J. Trujillo, I.-Y. Song, un perfil UML para modelado
multidimensional en almacenes de datos. Data Knowledge Eng. 59 (3), 725–769
(2006)
121. M. Maibaum, G. Rimon, C. Orengo, N. Martin, A. Poulovasillis, BioMap:
integración basada en familias de genes de bases de datos biológicas
heterogéneas utilizando metadatos de AutoMed, en Actas del 15o Taller
Internacional sobre Aplicaciones de Bases de Datos y Sistemas Expertos, DEXA
' 04 (IEEE Computer Society Press, 2004), págs. 384–388
122. M. Maibaum, L. Zamboulis, G. Rimon, C. Orengo, N. Martin, A. Poulovasillis,
Integración basada en clústeres de bases de datos biológicas heterogéneas
utilizando el kit de herramientas AutoMed, en Actas del 2do Taller
internacional sobre integración de datos en las ciencias biológicas , DILS 2005.
Lecture Notes in Computer Science, vol. 3615 (Springer, 2005), págs. 191–207
123. MI.Malinowski, E. Zimányi, Jerarquías en un modelo multidimensional: del
modelado conceptual a la representación lógica. Data Knowledge Eng. 59 (2), 348 a
377 (2006)
124. MI. Malinowski, MI. Zimányi, Inclusión oF tvariable de tiempo mesures en
temporal datos almacenes, en Actas de la 8ª Conferencia Internacional sobre
Sistemas de Información Empresarial, ICEIS'06, 2006, págs. 181–186
125. MI. Malinowski, MI. Zimányi, Reqrequisitos Especificacionesi fi cación
aDakota del Norte coconceptual mesdeling para almacenes de datos espaciales, en
Actas de los talleres de OTM 2006: En movimiento hacia sistemas de Internet
significativos. Notas de la conferencia en Ciencias de la Computación, vol. 4277
(Springer, 2006), págs. 1616-1625
Referenc 6
126. MI. Malinowski, E. Zimányi, Diseño avanzado de almacenes de datos: de
aplicaciones convencionales a espaciales y temporales (Springer, 2008)
127. E. Malinowski, E. Zimanyi, Un modelo conceptual para almacenes de datos
temporales y su transformación a ER y modelos relacionales de objetos. Data
Knowledge Eng. 64 (1), 101–133 (2008)
128. I. Mami, Z. Bellahsene, Un estudio de los métodos de selección de vistas. SIGMOD
Rec.
41(1), 20 a 29 (2012)
129. GRAMO. Marketos, E. Frentzos, I. Ntoutsi, N. Pelekis, A. Ra ff aetà, Y.
Theodoridis, Construyendo almacenes de trayectoria en el mundo real, en Actas del
7 ° Taller internacional de ACM sobre ingeniería de datos para acceso inalámbrico
y móvil (ACM, 2008), págs. 8 a 15
130. J.-NORTE. Mazón, J. Trujillo, M. Serrano, M. Piattini, Diseño de almacenes de
datos: Del análisis de requerimientos de negocio al modelado multidimensional, en
Avance del 1er Taller Internacional de Ingeniería de Requerimientos para
Necesidad de Negocios y Alineación de TI, REBN'05 , 2005, págs. 44–53
131. M. Mehta, R. Agrawal, J. Rissanen, SLIQ: un clasi fi cador escalable rápido para
minería de datos, en Actas de la 5ª Conferencia Internacional sobre Tecnología de
Bases de Datos Extendida, EDBT'96. Notas de la conferencia en Ciencias de la
132. J. Melton, SQL avanzado: 1999. Comprensión de las características relacionales de
objetos y otras características avanzadas (Morgan Kaufmann, 2003)
133. J. Melton, SQL: 2003 se ha publicado. SIGMOD Rec. 33 (1), 119 a 125 (2003)
134. J. Melton, A. Eisenberg, paquetes de aplicaciones y multimedia SQL (SQL /
MM). SIGMOD Rec. 30 (4), 97–102 (2001)
135. J. Melton, A. Simon, SQL: 1999. Comprensión de los componentes del lenguaje
relacional (Morgan Kaufmann, 2002)
136. A. Mendelzon, AA Vaisman, Consultas temporales en OLAP, en Proceedings of the
26th International Conference on Very Large Data Bases, VLDB'00 (Morgan
Kaufmann, 2000), págs. 243–253
137. A. Mendelzon, AA Vaisman, El tiempo en bases de datos multidimensionales, en
Bases de datos multidimensionales: Problemas y soluciones, ed. por M. Rafanelli
(Idea Group, 2003), págs. 166–199
138. J. Mennis, R. Viger, CD Tomlin, Funciones de álgebra de mapas cúbicos para
análisis espacio-temporal. Cartografía Geographic Inf. Sci. 32 (1), 17 a 32
(2005)
139. D. Moraschi, Business Intelligence con MicroStrategy Cookbook (publicación de
paquetes, 2012)
140. T. Morzy, R. Wrembel, On querying versions of multiversion data warehouse, en
Proceedings of the 7th ACM International Workshop on Data Warehousing y
OLAP, DOLAP'04 (ACM, 2004), págs. 92–101
141. IS Mumick, D. Quass, BS Mumick, Mantenimiento de cubos de datos y tablas de
resumen en un almacén, en Actas de la Conferencia Internacional ACM SIGMOD
sobre Gestión de Datos, SIGMOD'97 (ACM, 1997), págs. 100-111
142. V. Nebot, R. Berlanga Llavori, Construcción de almacenes de datos con datos
de web semántica. Decis. Soporte Syst. 52 (4), 853–868 (2011)
143. M. Neteler, H. Mitasova, SIG de código abierto: un enfoque de GRASS GIS, 3ª
ed. (Springer, 2008)
144. RT Ng et al., Perspectivas sobre inteligencia empresarial. Conferencias de
síntesis sobre gestión de datos (Morgan & Claypool, 2013)
145. METRO.Niinima¨ki, T. Niemi, Un proceso ETL para OLAP usando ontologías RDF
/ OWL, en Journal on Data Semantics XIII, ed. por S. Spaccapietra, E. Zimańyi,
I.-Y. Canción. Notas de la conferencia en Ciencias de la Computación, vol. 1396
(Springer, 2009), págs. 97-119
146. RO Obe, LS Hsu, PostGIS en acción, 2ª ed. (Publicaciones Manning Co., 2014)
6 Referenc
147. K. Oehler, J. Gruenes, C. Ilacqua, IBM Cognos TM1: La guía oficial

(McGraw-Hill, 2012)
148. A. O En Vivo, C onceptual Modelado de sistemas de información (Saltador, 2 0 0 7 )
149. EDUCACIÓN FÍSICA O'Neil, Arquitectura y desempeño del Modelo 204, en Actas
del 2do Taller Internacional sobre Sistemas de Transacción de Alto Desempeño.
págs. 40–59
150. E. O'Neil, G. Graefe, combinaciones de tablas múltiples mediante índices de
combinación de mapas de bits. SIGMOD Rec. 24 (3), 8 a 11 (1995)
151. S.Orlando, R. Orsini, A. Ra ff aetà, A. Roncato, C. Silvestri, Agregaciones espacio-
temporales en almacenes de datos de trayectoria. J. Comput. Sci. Ing. 1 (2), 211–
232 (2007)
152. F. Paim, J. Castro, DWARF: un enfoque para la de fi nición de requisitos y la
gestión de sistemas de almacenamiento de datos, en Proceedings of the 11th IEEE
International Requirements Engineering Conference, RE'03 (IEEE Computer
Society Press, 2003), págs. 75–84
153. F. Paim, A. Carvalho, J. Castro, Hacia una metodología para el análisis de
requisitos de los sistemas de almacenamiento de datos, en Actas del 16º Simposio
Brasileño de Ingeniería de Software, SBES'02, 2002, págs. 1-16
154. L. Paolino, G. Tortora, M. Sebillo, G. Vitiello, R. Laurini, Fenómenos: un
lenguaje de consulta visual para campos continuos, en Proceedings of the 11th
ACM Symposium on Advances in Geographic Information Systems, ACM-
GIS'03 ( ACM, 2003), págs. 147-153
155. C. Parent, S. Spaccapietra, E. Zimańyi, Modelado conceptual para aplicaciones
tradicionales y espacio-temporales: el enfoque MADS (Springer, 2006)
156. D. Parmenter, Indicadores clave de rendimiento (KPI): desarrollo, implementación
y uso de KPI ganadores, 2ª ed. (Wiley, 2010)
157. MR Patil, F. Thia, Pentaho para Big Data Analytics (Packt Publishing, 2013)
158. TB Pedersen, Gestión de datos multidimensionales complejos, en Proceedings of
the 2nd European Business Intelligence Summer School, eBISS 2012. Lecture
Notes in Business Information Processing, vol. 138 (Springer, 2012), págs. 1–28
159. TB Pedersen, CS Jensen, CE Dyreson, Ampliación de la agregación previa práctica
en el procesamiento analítico en línea, en Actas de la 25ª Conferencia
Internacional sobre Bases de Datos Muy Grandes, VLDB'99 (Morgan Kaufmann,
1999), págs. 663– 674
160. TB Pedersen, CS Jensen, C. Dyreson, Una base para capturar y consultar datos
multidimensionales complejos. Inf. Syst. 26 (5), 383–423 (2001)
161. norte. E d u c a c i ó n f í s i c a lekis, A . Ra ff aetà, ML Damiani, C. Vangenot, G.
Marketos, E. Frentzos,
I. Ntoutsi, Y. Theodoridis, Hacia almacenes de datos de trayectoria, en
Movilidad, minería de datos y privacidad: descubrimiento de conocimientos
geográficos, ed. por F. Giannotti, D. Pedreschi (Springer, 2008), Capítulo 9,
págs. 189–211
162. R. Persona, Cuadros de Mando Integral y Cuadros de Mando Operativos con
Microsoft Excel, 2ª ed. (Wiley, 2013)
163. T. Piasevoli, MDX con Microsoft SQL Server 2008 R2 Analysis Services
Cookbook (Packt Publishing, 2011)
164. H. Plattner, A. Zeier, Gestión de datos en memoria: tecnología y aplicaciones, 2ª
ed. (Morgan Kaufmann, 2012)
165. J. Pouliot, S. Daniel, F. Hubert, A. Zamyadi (eds.), Progreso y nuevas
tendencias en ciencias de la geoinformación 3D. (Springer, 2013)
166. E. Pourabbas, M. Rafanelli, Jerarquías, en Bases de datos multidimensionales:
problemas y soluciones, ed. por M. Rafanelli (Idea Group, 2003), págs. 91-115
167. A. Real academia de bellas artes ff aetà, L. Leonardi, GRAMO. Marketos,
GRAMO. Andrienko, norte. Andrienko, MI. Frentzos,
N. Giatrakos, S. Orlando, N. Pelekis, A. Roncato, C. Silvestri, Análisis de
movilidad visual usando T-Warehouse. En t. J. Data Warehousing Mining 7 (1),
1–23 (2011)
Referenc 6
168. R. Ramakrishnan, J. Gehrke, Sistemas de gestión de bases de datos, 3ª ed.
(McGraw-Hill, 2003)
169. NH Rasmussen, CY Chen, M. Bansal, Business Dashboards: A Visual Catalog for
Design and Deployment (Wiley, 2009)
170. F. Ravat, O. Teste, G. Zur fl uh, A multiversion-based multidimensional model, in
Proceedings of the 8th International Conference on Data Warehousing and
Knowledge Discovery, DaWaK'06. Notas de la conferencia en Ciencias de la
171. F. Ravat, O. Teste, R. Tournier, G. Zur fl uh, Top Keyword: una función de
agregación para el documento de texto OLAP, en Actas de la 10ª Conferencia
Internacional sobre Almacenamiento de Datos y Descubrimiento de
Conocimientos, DaWaK'08. Notas de la clase en Ciencias de la Computación, vol.
5182 (Springer, 2008), págs. 55–64
172. F. Reiss, S. Raghavan, R. Krishnamurthy, H. Zhu, S. Vaithyanathan, Un
enfoque algebraico para la extracción de información basada en reglas, en Actas
de la 24a Conferencia Internacional sobre Ingeniería de Datos, ICDE'08 (IEEE
Computer Society Press, 2008), págs. 933–942
173. C. Renso, S. Spaccapietra, E. Zimańyi (eds.), Mobility Data: Modeling,
Management, and Understanding (Cambridge Press, 2013)
174. pag. Rigaux, M. Scholl, A. Voisard, Bases de datos espaciales con aplicación a SIG
(Morgan Kaufmann, 2002)
175. M. Rittman, Guía para desarrolladores de Oracle Business Intelligence 11g
(McGraw-Hill / Osborne Media, 2012)
176. S.Rivest, Y. Bédard, P. Marchand, Hacia un mejor soporte para la toma de
decisiones espaciales: definiendo las características del procesamiento analítico
espacial en línea (SOLAP). Geomatica 55 (4), 539–555 (2001)
177. S. Rizzi, E. Saltarelli, Ver materialización frente a indexación: equilibrar las
limitaciones de espacio en el diseño de almacenes de datos, en Actas de la 15ª
Conferencia Internacional sobre Ingeniería Avanzada de Sistemas de
Información, CAiSE'03. Notas de la conferencia en Ciencias de la Computación,
vol. 2681 (Springer, 2003), págs. 502–519
178. I. Robinson, J. Webber, E. Eifrem, Bases de datos de gráficos (O'Reilly Media,
2013)
179. MCRoldań, Pentaho Data Integration: Beginner's Guide, 2nd edn. (Packt
Publishing, 2013)
180. O. Rom ero , A. Abelló, Automating multidimensional design from ontologies, in
Proceedings of the 10th ACM International Workshop on Data Warehousing y
OLAP, DOLAP'07 (ACM, 2007), págs. 1–8
181. O.Romero, A. Abelló, Sobre la necesidad de un álgebra de referencia para OLAP,
en Proceedings of the 9th International Conference on Data Warehousing and
Knowledge Discovery, DaWaK'07. Notas de la conferencia en Ciencias de la
Computación, vol. 4654 (Springer, 2007), págs. 99-110
182. M. Russo, A. Ferrari, C. Webb, Desarrollo de cubos expertos con Microsoft SQL
Server 2008 Analysis Services (Packt Publishing, 2009)
183. M. Russo, A. Ferrari, C. Webb, Servicios de análisis de Microsoft SQL Server
2012: el modelo tabular de BISM. (Microsoft Press, 2012)
184. C.Sapia, M. Blaschka, G. Ho fl ing, B. Dinter, Ampliación del modelo E / R para
paradigmas multidimensionales, en Actas de la 17ª Conferencia Internacional
sobre Modelado Conceptual, ER'98. Notas de la conferencia en Ciencias de la
185. DA Schneider, Consideraciones prácticas para la inteligencia empresarial en
tiempo real, en Actas del 1er Taller internacional sobre inteligencia empresarial
para empresas en tiempo real, BIRTE'06. Notas de la conferencia en Ciencias de la
186. JC Shafer, R. Agrawal, M. Mehta, SPRINT: un clasificador paralelo escalable para
la minería de datos, en Actas de la 22ª Conferencia Internacional sobre Bases de
Datos Muy Grandes, VLDB'96 (Morgan Kaufmann, 1996), págs. 544–555
6 Referenc
187. S. Shekhar, S. Chawla, Bases de datos espaciales: un recorrido (Prentice Hall,

2003)
188. A. Simitsis, Mapeo de modelos conceptuales a lógicos para procesos ETL, en Actas
del 8º Taller internacional de ACM sobre almacenamiento de datos y OLAP,
DOLAP'05 (ACM, 2005), págs. 67–76
189. BC Smith, CR Clay, Microsoft SQL Server 2008 MDX paso a paso (Microsoft
Press, 2009)
190. R. Srikant, R. Agrawal, Mining generalized association rules, en Proceedings of the
21st International Conference on Very Large Data Bases, VLDB'95 (Morgan
191. R. Srikant, R. Agrawal, Patrones secuenciales de minería: generalizaciones y
mejoras de rendimiento, en Actas de la 5ª Conferencia Internacional sobre la
192. K. Stockinger, K. Wu, Índices de mapa de bits para almacenes de datos, en
Almacenes de datos y OLAP: Conceptos, arquitecturas y soluciones, ed. por R.
Wrembel, C. Koncilia (IRM Press, 2007), capítulo 7, págs. 157-178
193. M. Stonebraker, Stonebraker en almacenes de datos. Comun. ACM 54 (5), 10–
11 (2011)
194. M. Stonebraker, DJ Abadi, A. Batkin, X. Chen, M. Cherniack, M. Ferreira,
E. Lau, A. Lin, S. Madden, E. O'Neil, P. O'Neil, A. Rasin, N. Tran, S. Zdonik, C-
Store: un DBMS orientado a columnas, en Proceedings of the 31ª Conferencia
Internacional sobre Bases de Datos Muy Grandes, VLDB'05 (Morgan
195. M. Stonebraker, DJ Abadi, DJ DeWitt, S. Madden, E. Paulson, A. Pavlo,
A. Rasin, MapReduce y DBMS paralelos: ¿amigos o enemigos? Comun. ACM
53(1), 64–71 (2010)
196. P.-N. Broncearse,M. Steinbach, V. Kumar, Introducción a la minería de datos,
2ª ed. (Addison-Wesley, 2013)
197. A. Tennick, Consultas prácticas de MDX: para Microsoft SQL Server Analysis
Services 2008 (McGraw-Hill, 2010)
198. TJ Teorey, SS Lightstone, T. Nadeau, HV Jagadish, Modelado y diseño de bases
de datos: Diseño lógico, 5ª ed. (Morgan Kaufmann, 2011)
199. C. Thomsen, TB Pedersen, Una encuesta de herramientas de código abierto para
inteligencia empresarial, en Integraciones de almacenamiento de datos, minería de
datos y tecnologías de bases de datos: enfoques innovadores, ed. por D. Taniar, L.
Chen (IGI Global, 2011), capítulo 10, págs. 237-257
200. CS Thomsen, TB Pedersen, W. Lehner, RiTE: suministro de datos bajo demanda
para el almacenamiento de datos en el momento adecuado, en Actas de la 24a
Conferencia Internacional sobre Ingeniería de Datos, ICDE'08 (IEEE Computer
Society Press, 2008), págs. 456 - 465
201. A. Thusoo, JS Sarma, N. Jain, Z. Shao, P. Chakka, N. Zhangand, S. Anthony,
H. Liu, R. Murthy, Hive: a petabyte scale data warehouse using Hadoop, in
Proceedings of the 26th International Conference on Data Engineering, ICDE
2010 (IEEE, Computer Society Press 2010), págs. 996–1005
202. D. Tomlin, Sistemas de información geográfica y modelado cartográfico (Pren- tice
Hall, 1990)
203. R. Torlone, Modelos conceptuales multidimensionales, en Bases de datos
multidimensionales: Problemas y soluciones, ed. por M. Rafanelli (Idea Group,
2003), págs. 69–90
204. J. Trujillo, M. Palomar, J. Gómez, I.-Y. Song, Diseño de data warehouses con
modelos conceptuales OO. Computación IEEE. 34 (12), 66 a 75 (2001)
205. N. Tryfona, F. Busborg, J. Borch, StarER: un modelo conceptual para el diseño de
un almacén de datos, en Proceedings of the 2nd ACM International Workshop on
Data Warehousing y OLAP, DOLAP'99 (ACM, 1999), págs. 3-8
Referenc 6
206. FSC Tseng, AYH Chou, El concepto de almacenamiento de documentos para el
modelado multidimensional de inteligencia empresarial basada en texto. Decis.
Soporte Syst. 42 (2), 727–744 (2006)
207. A. Tsois, N. Karayannidis, T. Sellis, MAC: modelado de datos conceptuales para
OLAP, en Proceedings of the 3rd International Workshop on Design and
Management of Data Warehouses, DMDW'01. Actas del taller del CEUR, 2001,
pág. 5
208. IZ Turki, FG Jedidi, R. Bouaziz, Restricciones del almacenamiento de datos de
múltiples versiones, en Actas del 13 ° Taller internacional de ACM sobre
almacenamiento de datos y OLAP, DOLAP 2010 (ACM, 2010), págs. 11–18
209. P. Turley, RM Bruckner, T. Silva, K. Withee, G. Paisley, Servicios de informes
profesionales de Microsoft SQL Server 2012 (Wrox, 2012)
210. AA Vaisman, Obtención de requisitos basados en la calidad de datos para
sistemas de soporte de decisiones, en Almacenes de datos y OLAP: Conceptos,
arquitecturas y soluciones, ed. por R. Wrembel, C. Koncilia (IRM Press, 2007),
capítulo 16, págs. 58–86
211. AA Vaisman, Introducción al modelado de procesos de negocio, en Actas de la
2ª Escuela de Verano de Inteligencia Empresarial Europea, eBISS 2012. Notas
de la conferencia sobre procesamiento de información empresarial, vol. 138
(Springer, 2012), págs. 29–61
212. AA Vaisman, E. Zimanyi, Un modelo multidimensional que representa campos
continuos en almacenes de datos espaciales, en Proceedings of the 17th ACM
SIGSPATIAL Symposium on Advances in Geographic Information Systems, ACM-
GIS'09 (ACM, 2009), págs. 168-177
213. A.A.Vaisman, E. Zimányi, ¿Qué es el almacenamiento de datos espacio-
temporales? en Actas de la XI Conferencia Internacional sobre Almacenamiento de
Datos y Descubrimiento de Conocimientos, DaWaK'09. Notas de la conferencia en
214. A.A.Vaisman, E. Zimányi, Diseño físico e implementación de almacenes de datos
espaciales que soportan campos continuos, en Actas de la 12ª Conferencia
Internacional sobre Almacenamiento de Datos y Descubrimiento del
Conocimiento, DaWaK'10. Notas de la clase en Ciencias de la Computación, vol.
6263 (Springer, 2010), págs. 25–39
215. A.A. Vi rg in ia es hombre, Esteban Zimányi, Dat a m e r c a n c í a casas:
Siguiente C desafíos, en P r o c e e D- ings de la 1st European Business Intelligence
Summer School, eBISS 2011. Lecture Notes in Business Information Processing,
vol. 96 (Springer, 2011), págs. 1 a 26
216. L. van den Brink, J. Stoter, S. Zlatanova, Establecimiento de un estándar
nacional para datos topográficos 3D que cumplen con CityGML. En t. J. Inf.
Geográfica. Sci. 27 (1), 92–113 (2013)
217. A. van Lamsweerde, Ingeniería de requisitos: de los objetivos del sistema a los
modelos UML y las especificaciones de software (Wiley, 2009)
218. Y. Vasiliev, Oracle Business Intelligence: The Condensed Guide to Analysis and
Reporting (Packt Publishing, 2010)
219. pag. Vassiliadis, Un estudio de la tecnología de extracción, transformación y
carga, en Integraciones de almacenamiento de datos, minería de datos y
tecnologías de bases de datos: enfoques innovadores, ed. por D. Taniar, L. Chen
(IGI Global, 2011), capítulo 8, págs. 171–199
220. pag. Vassiliadis, A. Simitsis, ETL en tiempo casi real, en Nuevas tendencias en
almacenamiento y análisis de datos, ed. por S. Kozielski, R. Wrembel. Annals of
Information Systems, vol. 3 (Springer, 2008), págs. 16–50
221. pag. Vassiliadis, A. Simitsis, S. Skiadopoulos, Modelización conceptual para
procesos ETL, en Actas del 5º Taller internacional de ACM sobre almacenamiento
de datos y OLAP, DOLAP'02 (ACM, 2002), págs. 14–21
222. SI Verdurasa López, R.T. Snodgrass, B. Luna, Espaciotemporal
a g r e g a d o miComputación: una encuesta. IEEE Trans. Knowledge Data Eng. 17
(2), 271–286 (2005)
223. J. Viqueira, N. Lorentzos, extensión SQL para datos espacio-temporales. VLDB
J.
6 dieciséis(2), 179–200 (2007)
Referenc
Referenc 6
224. G. Viswanathan, M. Schneider, Sobre los requisitos para el almacenamiento de
datos espaciales centrados en el usuario y SOLAP, en Actas de los talleres
DASFAA 2011, Lecture Notes in Computer Science, vol. 6637 (Springer, 2011),
págs. 144-155
225. D. Volitich, G. Ruppert, IBM Cognos Business Intelligence 10: La guía oficial
(McGraw-Hill, 2010)
226. T. White, Hadoop: The De fi nitive Guide, 3ª ed. (O'Reilly Media, 2012)
227. M. Whitehorn, R. Zare, M. Pasumansky, Fast Track to MDX, 2ª ed. (Springer,
2005)
228. IH Witten, E. Frank, MA Hall, Minería de datos: herramientas y técnicas
prácticas de aprendizaje automático, 3ª ed. (Morgan Kaufmann, 2011)
229. M. Worboys, M. Duckham, GIS: A Computing Perspective, 2ª ed. (Prensa CRC,
2004)
230. R. Wrembel, B. Bebel, Gestión de metadatos en un almacén de datos de
múltiples versiones, en Journal on Data Semantics VIII, ed. por S. Spaccapietra
et al. Notas de la conferencia en Ciencias de la Computación, vol. 4380
(Springer, 2007), págs. 118-157
231. R. Wrembel, T. Morzy, Gestión y consulta de la versión del almacén de datos de
múltiples versiones, en Actas de la 10ª Conferencia Internacional sobre la
232. K. Wu, EJ Otoo, A. Shoshani, Optimización de índices de mapa de bits con una
compresión eficiente. ACM Trans. Sistema de base de datos 31 (1), 1 a 38
(2006)
233. J.Xu, RH Gu¨ting, Un modelo de datos genérico para objetos en movimiento.
GeoInformática
17(1), 125-172 (2013)
234. AKW Yeung, GB Hall, Sistemas de bases de datos espaciales: diseño,
implementación y gestión de proyectos. Biblioteca GeoJournal, vol. 87 (Springer,
2007)
235. M. Yin, B. Wu, Z. Zeng, HMGraph OLAP: un marco novedoso para el análisis
de redes heterogéneas multidimensionales, en Proceedings of the 15th ACM
International Workshop on Data Warehousing y OLAP, DOLAP 2012 (ACM,
2012), págs. 137-144
236. F. Zemke, Novedades de SQL: 2011. SIGMOD Rec. 41 (1), 67 a 73 (2012)
237. D. Zhang, CX Zhai, J. Han, Cubo de temas: modelado de temas para OLAP en bases
de datos de texto multidimensionales, en Actas de la Conferencia Internacional
SIAM sobre Minería de Datos, SDM 2009, 2009, págs. 1123–1134
238. D. Zhang, CX Zhai, J. Han, AN Srivastava, NC Oza, Modelado de temas para
OLAP en bases de datos de texto multidimensionales: cubo de temas y sus
aplicaciones. Stat. Anal. Minería de datos 2 (5–6), 378–395 (2009)
239. pag. Zhao, X. Li, D. Xin, J. Han, Graph Cube: sobre almacenamiento y redes
multidimensionales OLAP, en Proceedings of the ACM SIGMOD International
Conference on Management of Data, SIGMOD 2011 (ACM, 2011), págs. 853–864
240. Y. Zheng, X. Zhou (eds.), Computación con trayectorias espaciales (Springer,
2011)
241. S. Zlatanova, Sobre relaciones topológicas 3D, en Actas de la 11ª Conferencia
Internacional sobre Aplicaciones de Bases de Datos y Sistemas Expertos, DEXA'00.
págs. 913–924
Índice
Propiedades ACID jerarquías multinivel o definidas por el

en bases de datos en usuario, 155
memoria, 517 en Oracle cálculos con nombre, 152
TimesTen, 525 consultas con nombre, 152
en SAP HANA, 523 jerarquías de padres e hijos, 159
Medidas aditivas, 58, 93 fraccionamiento, 269-273
Consultas ad hoc, 79 diseño físico, 269-275
Algoritmo aglomerativo, 338 rendimiento de la consulta, 274-275
Medidas algebraicas, 59 jerarquías irregulares, 160
Teclas alternativas, 23 dimensiones de referencia, 154
Jerarquías alternativas, 98-99 dimensiones regulares, 154, 155
en Analysis Services, 160 Almacenamiento ROLAP, 270
representación lógica, 134 dimensiones del juego de roles,
espacial, 439 154
Diseño basado en análisis, 81, 387, 415-416 medidas semiaditivas, 161
diseño conceptual, 402-407, 462-464 Análisis / diseño basado en fuentes, 81,
especificación de requisitos, 389-395, 387,
462-464 417-418
Servicios de análisis, 82, 152- diseño conceptual, 409-410, 466-467
163 especificación de requisitos, 401-402,
jerarquías de atributos, 155 466-467
Modelo semántico de inteligencia Cuadros de mando
empresarial, 82 analíticos, 372
miembros de datos, 159 Algoritmo a priori, 340
procesamiento de datos, Reglas de asociación, 338-347
350-362 vistas de en Analysis Services, 359-362
fuentes de datos, 152 confianza 339
fuentes de datos, 152 definido, 339
diagramas 153 jerárquico, 343
dimensiones de hecho, 154 reglas interesantes, 339
Almacenamiento HOLAP, 271 conjunto de elementos 339
implementación de jerarquías, minería de patrón de crecimiento, 344-
158-161 347 apoyo, 339
indicadores clave de rendimiento (KPI), Jerarquías de atributos
366-370 en Analysis Services, 155
dimensiones de varios a varios, 154, en Mondrian, 168
158 Atributos, 18
medir grupos, 161 derivado, 19
medidas, 161 de dimensiones, 55
Almacenamiento MOLAP, 271 de niveles, 91
A. Vaisman y E. Zimańyi, sistemas de almacenamiento de datos, siste

Referenc 6
mas y aplicaciones centrados en datos, DOI 10.1007 / 978-3-642-54655- 615
6,
6 Índ
obligatorio frente a opcional, 18 iniciar eventos, 288

monovaluado frente a multivalor, subprocesos, 287
18 nonprime, 29 carriles, 290
principal, 29 terminar eventos, 289
de relaciones, 21 eventos de tiempo,
simple versus complejo, 288 tareas de datos
19 espacial, 436, 448-450 unarios, 293
Mesas puente, 135
Árboles B +, 46
Nivel de back-end, 76-77 Árboles B, 46
Jerarquías equilibradas, 57, Cubos, 45
95 en Analysis Services, Bu ff er, 44
159 Inteligencia de Negocio, 3
representación lógica, 129-130 Metadatos comerciales, 78, 392
espacial, 438
IRI base, 544
Tipos de relaciones binarias, Almacenamiento en caché, 45
18 Compresión de mapa de en bases de datos en
bits, 259-260 memoria, 517 en Mondrian,
Filtros de mapa de bits, 269 277-278
Índices de mapa de bits, 235, 257-260 en MonetDB / X100, 522
Diseño de abajo hacia arriba, 14, en Oracle TimesTen, 524
80, 386 Forma normal de Boyce- tiempo real, 531
Codd, 30 BPMN (Modelado de Cardinalidades
procesos de negocio de atributos, 18
Notación), 286-309 entre hechos y niveles, 91
ocupaciones, 286 de las relaciones entre padres e
anotaciones, 290 hijos, 93 de roles, 18
artefactos 290 Funcionamiento del producto
asociaciones, 289 cartesiano, 32 Celdas, ver
cancelar eventos, 288 hechos
eventos de compensación, 288 Verifique las restricciones, 23, 133, 450
pasarelas complejas, 288 fl ujos Puestos de control, 517
de secuencia condicional, 289 en Oracle TimesTen,
conectando objetos, 289 525 Niveles infantiles, 56,
tareas de control, 292 93
objeto de datos, 290 Clasificación, 331
tareas de datos, 292 supervisado 333-336 sin
fl ujos predeterminados, 289 supervisión, consulte Agrupación
eventos finales, 288 Herramientas del cliente, 76
eventos, 288 Índices agrupados, 45
pasarelas exclusivas, 287 Agrupación, 331, 336-338
fl ujo de objetos, 286 en Analysis Services, 355-358
para ETL, 291-295 entre variación de racimo, 337
pasarelas, 287 definido, 336
grupo, 290 distancia, 337
pasarelas inclusivas, 287 jerárquico, 338
carriles 290 función de puntuación, 337
bucles 289 dentro de la variación del
eventos de mensajes, 288 racimo, 337 Colisión, 45
fl ujos de mensajes, 289 Bases de datos de almacenamiento de
norte -tareas de datos columnas, 514-515
generales, 293 pasarelas compresión, 515
paralelas, 288 índices, 526-527
quinielas, 290 MonetDB, 520-522
operaciones de fila, 293 Vertica, 519-520
operaciones de conjuntos de filas, Índices de almacén de columnas, 269, 526-
293 527 Columnas, ver atributos
Flujos de secuencia, 289 Atributos complejos, 19
Índ 6
Claves compuestas, 23 Carga de datos, 77
Partición compuesta, 266
Compresión
en bases de datos de
almacenamiento de columnas,
515 en MonetDB / X100, 522
en Oracle TimesTen,
525 en SAP HANA, 524
Diseño conceptual
impulsado por análisis, 402-407, 462-
464
análisis / basado en fuentes, 409-410,
466-467
para bases de datos, 5, 14, dieciséis-21
para almacenes de datos, 89-115, 402-
418
impulsado por fuentes, 407-409, 464-
466
para almacenes de datos espaciales,
434-442, 462-467
Modelos conceptuales, 5, 14
Esquemas conceptuales, 89
Esquemas de constelaciones, 125
Restricciones
topológico 436-437, 452-453, 492
Campos continuos, 432-434
Trayectorias continuas, 476
Algoritmo de conteo, 237
Estimación del tamaño del
cubo, 250-251
algoritmo analítico, 250 algoritmo de
conteo probabilístico, 251 algoritmo
basado en muestreo, 251
Cubos, ver cubos de datos
CWM (modelo de almacén común), 115
Cuadros de mando, 7, 370-378

analítico, 372
definido, 371
Operacional, 372
en Reporting Services, 373-378
estratégico, 371
Envejecimiento de datos, 518
en Oracle TimesTen,
525 Análisis de datos, 3, 7
Base de datos (s), 13
Bloques de base de datos, 44
Páginas de base de datos, 44
Cubos de datos, 54
enrejado, 246
cálculo parcial, 251-255
estimación de tamaño,
250-251 escaso versus
denso, 55
Extracción de datos, 76
Independencia de datos 15
lógico versus físico, 15
Latencia de datos, 528
6
Data marts, 74, 76, 78, 386
Índ
Procesamiento de datos, 3, 7, 330-362
definido, 330
modelos 331
patrones, 331
herramientas, 79
Minería de datos en Analysis Services,
350-362
reglas de asociación, 359-362
agrupamiento, 355-358
consulta de contenido, 353
árboles de decisión, 352-355
consulta de predicción,
353 Modelos de datos
ER (entidad-relación), dieciséis-21
multidimensional, 5, 53-72
relacional, 21-36
Actualización de datos, 77
Fuentes de datos, 76
interno vs externo, 76
Área de almacenamiento
de datos, 76
Arquitectura de
almacenamiento de datos,
517 en bases de datos en
memoria, 517 en
MonetDB / X100, 521
en Oracle TimesTen,
524 en SAP HANA, 523
Transformación de datos, 76
Tipos de datos, 22
campos, 432-434
espacial, 428-432
temporal, 477-490
Almacenes de datos, 3, 4, 54, 72-80
arquitectura, 76-80
comparación con operacional
bases de datos, 74-75
definido, 72
empresa, 76, 77
índices para, 256-261
integrado, 5
carga de, 77
No volátil, 5
tiempo real, 528-532
refrescante de, 77
tiempo correcto, 531
espacial, 427-468
orientado al tema, 4
nivel, 76-78
variable en el tiempo, 5
trayectoria, 475-503
virtual, 80
Dato, 443
DBMS (sistemas de gestión de
bases de datos), 13
DDL (lenguaje de definición de datos),
35
Índ 6
Almacenes de datos espaciales 3D / 4D, Almacenes de datos empresariales, 76, 77
579-581 Sistemas de Soporte a la Entidades, dieciséis
Decisión, 3 Tipos de entidad, dieciséis
Árboles de decisión, 334 identificando, 19
en Analysis Services, 352-355 población de,
Dimensiones degeneradas, ver hecho dieciséis fuerte
dimensiones contra débil, 19
Cubos de datos densos, 55 Modelo ER (entidad-relación), dieciséis-
Índices densos, 46 21 transformándose en lo relacional
Dependencias modelo, 24-27
funcional, 28 ETL (extracción, transformación y carga),
multivalor 28 7, 76, 413
Atributos derivados, 19 herramientas, 76
Medidas derivadas, 93 Relaciones exclusivas entre padres e
Modelos descriptivos, 331 hijos, 94 Análisis exploratorio de datos,
Método de diseño 331 Fuentes de datos externas, 76
de abajo hacia arriba, 14, 80, 386
De arriba hacia abajo, 14, 80, 386
Operación de diferencia, 32
Dimensiones, 5, 54, 90
Hecho dimensiones, 127, 158
atributos de, 55
en Analysis Services, 154, 158
hecho, 127, 154
en Mondrian, 171
en vez de, 56
Miembros de hecho, 91
niveles, 55
Tablas de hechos, 123
muchos a muchos, 106-110, 138-139,
Hechos, 5, 55, 91
154
espacial, 436, 450-453
miembros 55
con múltiples granularidades,
juego de rol, 93, 127, 154, 168
106, 137-138
esquema de, 56
Algoritmo de actualización rápida,
cambiando lentamente, 139-145 341-343 Tipos de campo, 432-434
espacial, 436 levantamiento de operaciones, 434
mesas, 123 operaciones de tasa de cambio, 433-434
Trayectorias discretas, 476 temporal, 483-485
Generalizaciones desarticuladas, 21 Campos de un registro,
Bloques de disco, 44 44 Organización de
Páginas de disco, 44 archivos, 45
Almacenamiento de disco, 43 definido, 45
Distribuir atributos, 94, 104 archivos hash, 45
Medidas distributivas, 59 archivos de montón, 45
Algoritmos divisivos, 338 archivos ordenados, 45
DML (lenguaje de manipulación de archivos secuenciales, 45
datos), 35 DMX (extensiones de minería archivos desordenados, 45
de datos), 82, 350 Archivos 44
consultas de contenido, 350 Primera forma normal,
para el estudio de caso de Northwind, 29 Llaves extranjeras, 23
353-362 consultas de predicción, 350 Cuarta forma normal,
Dominios 22 30 FP-árbol
Cuenta doble, 103-110 Índices minería de patrón de
dinámicos multinivel, 46 crecimiento, 344
Fragmentación, consulte
Partición de conjuntos de
elementos frecuentes, 339
Inclusión temprana de soporte espacial, Nivel de front-end, 76, 79
462 Elipsoide 442 Operación de unión externa
ELT (extracción, carga y completa, 34 Dependencias
transformación), 532-534 funcionales, 28
parcial, 29
transitivo, 29
Requerimientos funcionales, 391
6 Índ
Relaciones de generalización, 20 Algoritmo ID3, 335

disjuntos versus superpuestos, Identificadores, 19
21 total vs parcial, 21 de tipos de
Jerarquías generalizadas, 96- entidad, 19 de
98 en Analysis Services, 160 niveles, 91
representación lógica, 132-134 parcial, 20
espacial, 438 Identificar tipos de entidades, 19
Geoide 442 Identificar tipos de relaciones, 19
Geometría, 436 Mantenimiento de vista
GeoMondrian, 454-459 Estudio de incremental, 236 Vistas indexadas,
caso de GeoNorthwind, 434-438, 266-268
454-461 alineado con partición, 267-268
consultar en MDX, 455-459 Índices, 45-46, 234-235
consultar en SQL, 459-461 mapa de bits 235, 257-260
Índice de Gini, 335 agrupados frente a no
SIG (sistemas de información agrupados, 45 columna-
geográfica), 8 tienda, 269, 526-527
Análisis de gráficos, 586 definido, 45
Almacenes de datos gráficos, 586-588 multinivel dinámico, 46
para almacenes de datos, 256-
261 entrar, 235, 260-261
Hadoop, 508 primaria vs secundaria, 45
rastreador de trabajos, 508 una columna frente a varias columnas,
rastreador de tareas, 508 45 de un solo nivel frente a varios
Archivos hash, 45 niveles, 46
Funciones hash, 45 escaso versus denso, 46
Partición hash, 265 único frente a no único,
Archivos de montón, 45 45
Reglas de asociación jerárquica, Indexación, 414
343 Agrupación jerárquica, 338 Campos de indexación, 45
algoritmos aglomerativos, 338 Herencia, 20
algoritmos divisivos, 338 Bases de datos en memoria,
Jerarquías, 6, 56, 93-106, 129-135 516-518 datos activos frente
alternativa, 98-99, 134, 439 a pasivos, 518
equilibrado, 57, 95, 129-130, 438 almacenamiento en caché
generalizado 96-98, 132-134, 438 517
implementación en Analysis Services, envejecimiento de datos, 518
158-161 Oracle TimesTen, 524-525
representación lógica, 129-135 SAP HANA, 522-524
no estricto 102-106, 135-136, 439 Operaciones de unión interna frente a
paralelo, 99-102, 134-135, 439 externa, 34 Instancias
harapiento, 98, 134 de dimensiones, 56
recursivo o padre-hijo, 66, 95-96, de tipos de
131 entidad, dieciséis
espacial, 436, 438-439, 450-453 de hechos, consulte
estricto versus no estricto, 102 Miembros de hechos de
desequilibrado, 95-96, 130-131 niveles, consulte Miembros
Nombre de la jerarquía, 93 de tipos de relaciones, 18 Servicios
Colmena, 510-512 de integración, 82, 309-310,
HOLAP (OLAP híbrido), 122 312-319
en Analysis Services, 271 Restricciones de integridad,
Medidas holísticas, 59 23-24
Partición horizontal, 235, 264 comprobar las limitaciones, 23,
Hipercubos, ver cubos de datos 133, 450 para jerarquías
generalizadas, 133 llaves, 23
no nulo, 23
integridad referencial, 23, 123,
124 Fuentes de datos internas, 76
IRI (identificador de recursos
Índ
internacionalizados), 540
6
relaciones is-a, Ver relaciones de
generalización
Conjunto de elementos
reglas de asociación, 339
6 Índ
Unir índices, 235, 260-261 definido, 234

Unión de tablas particionadas, reescritura de consultas, 234
264 Unirse a la operación, 33 selección de, 234
Uniendo niveles, 97 actualización de, 234
MDX (expresiones multidimensionales),
82, 179-216
Pava, 83, 311-312, 319-324 para definir KPI, 367-370
Llaves, 23 para datos espaciales, 455-
alterno, 23 459
primario, 23 Medidas, 5, 55, 57-59, 92
simple vs compuesto, 23 aditivo, 58, 93
Algoritmo de K-medias, 337 algebraico, 59
Descubrimiento de conocimiento en derivado, 93
bases de datos, 330 KPI (indicadores distributivo, 59
clave de rendimiento), 7, holístico 59
362-370 no aditivo, 58, 93
en Analysis Services, 366-370 clasi fi semiaditivo, 58, 93
cación, 363-364 espacial, 437, 440-442, 450-453
definido, 362 espaciotemporal, 492
Miembros 55, 90
Metadatos 78
Inclusión tardía de soporte espacial, negocio, 78, 392
462 Latitud, 443 repositorio, 76
Niveles de hojas, 93 técnico, 78, 392, 397
Operación de unión externa Minidimensiones, 143
izquierda, 34 Niveles 90 MOLAP (OLAP multidimensional), 122
niño, 93 en Analysis Services, 271
dimensiones, 55 Mondrian, 83, 164-172
unión, 97 tablas agregadas, 276-277
hoja, 93 jerarquías de atributos, 168
padre, 93 almacenamiento en caché 277-278
raíz, 93 columnas calculadas, 166
espacial, 436, 448-450 medidas calculadas, 172
terrible, 97 mesas de cierre, 277, 319
Levantamiento de operaciones, 434, 480, esquema de cubo, 164
482-485 miembros de datos, 170
Partición de listas, 265 dimensiones de hecho, 171
Independencia lógica de los medir grupos, 172
datos, 15 Diseño lógico medidas, 172
para bases de datos, 5, 6, 14, jerarquías multinivel, 167
21-30 para almacenes de datos, jerarquías de padres e hijos, 169
121-135, diseño físico, 276-278
410-413
esquemas físicos, 165
para almacenes de datos espaciales,
jerarquías irregulares, 170
467 Modelos lógicos, 14
dimensiones del juego de roles, 168
Longitud, 443
dimensiones compartidas, 165, 168
esquemas de copos de nieve, 166, 169
MonetDB, 520-521
Análisis MAD, 532
tabla de asociación binaria, 520
Atributos obligatorios, 18
MonetDB / X100, 521-522
Roles obligatorios, 18 administrador del búfer de columna,
Dimensiones de varios a 522 compresión, 522
varios en Analysis arquitectura de
Services, 154 almacenamiento de datos,
Tipos de relaciones de varios a varios, 521 procesamiento en caché,
18 Proyección de mapas, 443 522
Mapa reducido, 508-514 ejecución vectorizada, 522
Vistas materializadas, 234-240, 415
Índ 6
Atributos monovaluados, 18 esquema lógico de la base de datos, 22
Roles monovaluados, 18 minería de datos en Analysis
Mover bases de datos de Services, 350-362
objetos, 477 Objetos en preparación de datos para minería de
movimiento, 9, 476 datos, 332-333
Modelo MultiDim, 6, 89-115 descripción, 15-dieciséis
representación lógica, 126-135, Proceso ETL en Integration Services,
448-453 312-319
extensión espacial, 434-442 Proceso ETL en Kettle, 319-324
Modelos multidimensionales, 5, 53-72 ampliado con datos espaciales, 434-
Formas normales multidimensionales, 107 438,
Esquemas multidimensionales, 90 454-461
Índices multinivel, 46 KPI en Analysis Services, 366-370
Almacenes de datos multimedia, 583-586 diseño de almacén de datos lógico,
Múltiples granularidades, 106, 137-138 411-413
Múltiples representaciones, 581 diseño de almacén de datos físico,
Índices de varias columnas, 45 413-415
Atributos multivalor, 18 consultar en MDX, 207-216, 455-459
Dependencias multivalor, 28 consultas en SPARQL, 564-573
Roles de múltiples valores, 18 consultar en SQL, 216-225, 459-461,
Almacenes de datos musicales, 585 495-502
consultar utilizando las operaciones
OLAP, 110-114
norte-Tipos de relaciones, Representación RDF, 561-564
18 ETL casi en tiempo real, especificación de requisitos, 392-395,
529 Restricciones no nulas, 398-401, 464
23 almacén de datos de trayectoria, 490-
Medidas no aditivas, 58, 93 502 Valores nulos, 23
Índices no agrupados, 45
Requerimientos no
funcionales, OLAP (procesamiento analítico en línea),
392 3, 54
Atributos no preferenciales, 29 servidores, 76
Jerarquías no estrictas, 102-106 herramientas, 79
en Analysis Services, 160 Operaciones OLAP, 59-72
representación lógica, 135-136 añadir medida, 64, 68
espacial, 439 funciones de agregación acumulativa, 69
Índices no únicos, 45 dado, 64, 67
Formas normales, 29 diferencia, 72
Boyce-Codd, 30 perforar, 64, 68
primero, 29 profundizar, 63, 66
cuatro, 30 perforar a través, 72
multidimensional, 107 medida de gota, 68
segundo, 29 filtrar funciones de agregación, 69
tercera, 29 max, 64
Normalización, 27-30 pivotar o rotar, 64, 67
Estudio de caso de rebautizar, 67
Northwind enrollar, 59, sesenta y cinco
diseño de almacén de datos conceptual, rodaja, 64, 67
404-409, 464 clasificar, 64, 66
proceso ETL conceptual, 295-309 de suma, 64
fi nición de cubo en Analysis Services, porcentaje superior, 64
152-163 Unión, 71
definición de cubo en Mondrian, 164- Nivel OLAP, 76, 78-79
172 cuadros de mando en Reporting
Services,
373-378
esquema conceptual de la base de
datos, 17
6 Índ
OLTP (procesamiento de transacciones vertical, 235, 264

en línea), 54 Descubrimiento de patrones, 332
Tipos de relaciones de uno a varios,
18 Tipos de relaciones uno a uno,
18 Cuadros de mando operativos,
372
Bases de datos operativas, 4, 54
comparación con almacenes de
datos,
74-75
Almacén de datos operativos, 77
Atributos opcionales, 18
Roles opcionales, 18
Oracle Exalytics, 525
Oracle TimesTen, 524-525
Propiedades ACID, 525
puestos de control, 525
compresión, 525
envejecimiento de datos, 525
arquitectura de
almacenamiento de datos, 524
caché de base de datos en
memoria, 524
Archivos ordenados, 45
Campos de pedidos, 45
Generalizaciones superpuestas, 21
Tipos de entidad propietaria,
consulte Identificación
tipos de entidad
Jerarquías paralelas, 99-102

en Analysis Services, 160
independiente vs.dependiente,
99 representación lógica, 134-
135
espacial, 439
Jerarquías de padres e hijos, 66, 95-96,
131 en Analysis Services, 159
en Mondrian, 169
Relaciones entre padres e hijos, 93
exclusivo, 94
Niveles de padres, 56, 93
Cálculo parcial de un cubo de datos,
251-255
Dependencias funcionales
parciales, 29 Generalizaciones
parciales, 21
Identificadores parciales, 20
Vistas indexadas alineadas por partición,
267-268 Poda de partición, 264
Fraccionamiento, 235, 263-266,
414 en Analysis Services, 269-
273 definido, 235
horizontal, 235, 264
en MonetDB, 520
tiempo real, 529
en SAP HANA, 523
en Vertica, 520
Índ
Minería de crecimiento de en Analysis Services, 160
6
patrones, 344-347 FP-árbol, representación lógica, 134
344
Carga máxima, 43
Pentaho Business Analytics, 83-84
Diseñador de agregaciones, 84
Analysis Services o Mondrian, 83, 164-
172, 276-278
Plataforma de análisis de
negocios, 83 Integración de
datos o hervidor, 83,
311-312, 319-324
Minería de datos o Weka,
83 Editor de metadatos, 84
Diseñador de informes, 83
Banco de trabajo de
esquema, 84 Independencia
de datos físicos, 15 Diseño
físico
en Analysis Services, 269-275
para bases de datos, 5, 6, 14,
43-46 para almacenes de
datos, 233-279,
413-415
indexación, 414
vistas materializadas, 415
en Mondrian, 276-278
fraccionamiento, 414
para almacenes de datos
espaciales, 467 modos de
almacenamiento, 414
Modelos físicos,
14 Esquemas
físicos
en Mondrian, 165
Jerga, 512-514
Algoritmo PipeSort,
247 Población
de tipos de entidad,
dieciséis inclusión,
20
de tipos de relaciones, 18
Consultas predefinidas, 79
Modelos predictivos, 331
Índices primarios, 45
Llaves primarias, 23
Atributos principales, 29
Operación de proyección, 31
Vocabulario QB4OLAP, 557-

561
Operaciones OLAP, 559-561
Vocabulario QB, 553-
557
Operaciones OLAP, 556-557
Reescritura de consultas, 234
Query-update trade-o ff, 44
Jerarquías irregulares 98
6 Índ
en Mondrian, 170 recursivo 18

espacial, 438 regular, 19
Partición de rango, 265
Modelo de trama, 446-448
Tasa de operaciones de cambio, 433-434,
483 RDF (marco de descripción de
recursos),
540
Representación RDF de datos
relacionales, 543-547
mapeo directo, 544
R2RML, 545-547 RDFS
(esquema RDF), 540
RDF / XML, 541
Almacenes de datos en tiempo real, 10,
528-532
almacenamiento en
caché de datos, 531
alimentación directa
por goteo, 531 goteo y
volteo, 531
Particiones en tiempo real, 529
Registros, 44
Jerarquías recursivas, consulte
Jerarquías de padres e hijos
Tipos de relaciones recursivas, 18
Integridad referencial, 23
en esquemas de copos de
nieve, 124 en esquemas de
estrella, 123
Actualizar algoritmo, 242
Regresión, 331
Tipos de relaciones regulares, 19
Álgebra relacional, 30-35
operaciones básicas vs derivadas, 30
Producto cartesiano, 32
diferencia, 32
unión externa completa, 34
uniones internas versus
externas, 34 entrar, 33
izquierda
combinación
externa, 34
proyección, 31
rebautizar, 31
unión externa derecha,
34 selección, 31
operaciones unarias frente a
operaciones binarias, 30 Unión, 32
Modelo relacional, 21-36
Esquema relacional, 21
Relaciones, 21
Tipos de relaciones dieciséis
binario, 18
identificando, 19
norte-ary, 18
uno a uno, uno a muchos y
muchos a muchos, 18
población de, 18
Índ
Relaciones, 18 Segmentación de trayectorias, 490, 493
6
topológico 8, 430-431 Operación de selección, 31
Cambiar el nombre de la operación, 31 Funciones agregadas auto-sostenibles,
Replicación, 517 241
Servicios de informes, 82
cuadros de mando, 373-378
Herramientas de informes
79 Especificación de
requisitos
impulsado por análisis, 387, 389-395,
462-464
análisis / basado en fuentes, 387, 401-
402,
466-467
para bases de datos, 5,
14
para almacenes de datos, 389-402
impulsado por fuentes, 387, 396-401,
464-466 para almacenes de datos
espaciales, 462-467
Tiempo de respuesta, 43
Operación de unión externa
derecha, 34 Almacenes de
datos en el momento
adecuado, 531 ETL en el
momento adecuado, 531
ROLAP (OLAP relacional), 122
en Analysis Services, 270
Dimensiones del juego de roles,
93, 127 en Analysis Services,
154
en Mondrian, 168
Roles, 18
monovaluado frente a
multivalor, 18 en esquemas
multidimensionales, 91
nombres de, 18
opcional frente a
obligatorio, 18 Niveles de
raíces, 93
Filas, ver tuplas
Codificación de longitud de ejecución, 259
SAP HANA, 522-524

Propiedades ACID, 523
compresión, 524
arquitectura de
almacenamiento de datos,
523 fraccionamiento, 523
puntos de guardado, 523
Puntos de guardado, 517
en SAP HANA, 523
Esquemas
conceptual, 89
de dimensiones, 56
multidimensional,
90 Segunda forma
normal, 29 Índices
secundarios, 45
Almacenamiento secundario, 44
6 Índ
Vistas auto-sostenibles, 239 componente espacial, 428

Web semántica, 10, 540 Sistemas de referencia espacial, 442-
Medidas semiaditivas, 58, 93 443 Valores espaciales
Archivos secuenciales, 45 Perímetro, 430
Minería de patrones secuenciales, exterior, 430
348 Patrones secuenciales, 332, 347- interior, 430
349 Similitud de trayectorias, 494 Bases de datos espacio-temporales, 477
Atributos simples, 19 Almacenes de datos espacio-temporales,
Llaves simples, 23 477 Medidas espacio-temporales, 492
Índices de una sola columna, 45 División de niveles, 97
Índices de un solo nivel, 46 SQL (lenguaje de consulta estructurado),
Dimensiones que cambian lentamente, 35-43 agregación y clasificación, 38-40
139-145 Esquemas de copos de nieve, 6, expresiones de tabla comunes, 42-43
124, 129, 130 creando esquemas relacionales, 35-36
en Mondrian, 166, 169 DDL (lenguaje de definición de datos),
Diseño basado en fuentes, 81, 387, 416- 35 DML (lenguaje de manipulación de
417 datos),
diseño conceptual, 407-409, 464-466 35
especificación de requisitos, 396-401, SQL / MM, 443-446
464-466 SQL / OLAP, 145-151
Intercambio de espacio-tiempo, 43 subconsultas, 40-41
SPARQL, 547-551 puntos de vista, 41-42
agregación y clasificación, 549-550 Servidor SQL, 82-83
subconsultas, 550-551 Servicios de análisis, 82, 152-163,
Cubos de datos dispersos, 269-275, 350-362, 366-370
55 Índices dispersos, 46 índices de almacén de columnas, 269
Atributos espaciales, 436 vistas indexadas, 266-268
implementación relacional, 448-450 Servicios de integración, 82, 309-310,
Datos espaciales, 8 312-319
Tipos de datos espaciales, 428-432 Estudio de gestión, 82
temporal, 481-485 Servicios de informes, 82, 373-
Almacenes de datos espaciales, 8, 427- 378 Herramientas de datos de
468 SQL Server, 82
Bases de datos espaciales, 8
SQL Server xVelocity, 526-528
Dimensiones espaciales, 436 procesamiento por lotes, 526,
Hechos espaciales, 436 527
implementación relacional, 450-453 índices de almacén de columnas, 526
Jerarquías espaciales, 436, 438-439 directorio de segmentos, 527
alternativa, 439 Esquemas de copos de estrellas, 125
equilibrado, 438 Consultas estrella, 261-263
generalizado 438 Esquemas de estrella, 6, 123, 130
no estricto 439 Herramientas estadísticas, 79
paralelo, 439 Cuadros de mando estratégicos, 371
harapiento, 438 Estrictas jerarquías, 102
implementación relacional, 450-453 Tipos de entidades
Niveles espaciales, 436 fuertes, 19 Reglas fuertes,
implementación relacional, 448-450 339
Medidas espaciales, 437, 440-442 Sustituibilidad, 20
implementación relacional, 450-453 Subtipos, 20
Modelos espaciales Resumibilidad, 57
basado en el campo, 428, 432-434 Algoritmo resumen-delta, 241
basado en objetos 428-432 Tabla resumen-delta, 241
trama 446-448 Tablas de resumen, 240
vector, 443-446 Supertipos, 20
Objetos espaciales, 428 Clasi fi cación supervisada, 333-336
componente descriptivo, 428 identidad de clase, 333
cambios discretos, 476 equipo de prueba, 333
conjunto de entrenamiento, 333
Índ 6
Tablas, ver relaciones Índices únicos, 45
Metadatos técnicos, 78, 392, 397 Archivos desordenados, 45
Bases de datos temporales, 478, 578 Clasificación no supervisada, ver
Almacenes de datos temporales, 577- Agrupación
579 Tipos temporales, 477-490 URI (identificador de recurso universal),
operaciones de agregación, 479 540 URL (localizador de recursos
campo 483-485 universal), 540
implementación en PostGIS, 485-490
levantamiento de operaciones, 480,
482-485
operaciones de tasa de cambio, 479, Tiempo valido, 478, 486
483 Modelo vectorial 443-446
espacial, 481-485 Vertica, 519-520
Mosaico, 446 fraccionamiento, 520
Análisis de texto, 581 tienda optimizada para lectura, 519
Almacenes de datos de texto, 581- segmentación, 520
583 Tercera forma normal, 29 tienda optimizada para escritura, 519
Diseño de arriba hacia abajo, 14, 80, 386 Partición vertical, 235, 264 Vertipaq,
Restricciones topológicas, 436-437, consulte el mantenimiento de SQL
452-453, 492 Server xVelocity View, 236
Relaciones topológicas, 8, 430-431 Ver algoritmo de beneficio de
Generalizaciones totales, 21 materialización, 253
Trayectorias, 9 Puntos de vista, 41-42
continuo frente a discreto, 476 definido, 234
segmentación de, 490, 493 atributo distinguido, 240
similitud de, 494 atributo expuesto, 240
Almacenes de datos de trayectoria, 9, mantenimiento incremental, 236
475-503 indexado, 266-268
Bases de datos transaccionales, 4 mantenimiento, 236
Rendimiento de transacciones, 43 materializado, 234-240
Tiempo de transacción, 478 autosuficiente, 239 Ver
Dependencias funcionales transitivas, 29 algoritmo de selección, 253
Disparadores 24
Tuplas 23
Tortuga, 541 Tipos de entidades débiles,
19 Weka, 83
Marco de ventana, 150
Jerarquías desequilibradas, 95-
Orden de ventana, 149
96 en Analysis Services, 159
Partición de ventanas, 149
representación lógica, 130-131
Operación sindical, 32

Data Warehouse Systems - Design and Implementation (PDFDrive) - Part4.en - Es

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Data Warehouse Systems - Design and Implementation (PDFDrive) - Part4.en - Es

Cargado por

Copyright:

Formatos disponibles

11.

8 Diseño de almacén de datos 1

La fase de diseño conceptual (Fig. 11.16b) comienza con el desarrollo del

Inclusión tardía de apoyo espacial

Puede suceder que los usuarios no estén familiarizados con la gestión de

Enfoque basado en fuentes

Inclusión temprana de apoyo espacial

Si los sistemas de origen incluyen datos espaciales, se pueden aplicar pasos

Inclusión tardía de apoyo espacial

la identificación de los sistemas de origen que pueden servir como

Inclusión tardía de apoyo espacial

Este caso ocurre cuando los sistemas de origen no incluyen datos

Enfoque basado en análisis / fuente

B Inclusión tardía de apoyo espacial

Definir esquema conceptual inicial

Definir esquema conceptual inicial

Este enfoque combina los dos enfoques descritos anteriormente que se

datos y si los sistemas de origen incluyen datos espaciales. La discusión

11.8.2 Lógico y diseño físico

En este capítulo, estudiamos cómo se pueden ampliar los almacenes de

11.10 Notas bibliográficas

Hay muchos libros sobre bases de datos espaciales y sistemas de

11.11 Preguntas de revisión

11.1 Considere el cubo GeoFoodmart, cuyo esquema se muestra en la Fig.

Nombre de la promoción Ventas

Figura 11.19 Esquema conceptual del cubo GeoFoodmart

(c) Muestre las ventas unitarias por marca de producto,

product_class_id product_subcategory categoría_producto departamento

Figura 11.20 Esquema relacional del almacén de datos de GeoFoodmart

El capítulo anterior se centró en el análisis de las características espaciales

A. Vaisman y E. Zima´nyi, sistemas de almacenamiento de datos, 475

12.1 Análisis de datos de movilidad

Hoy en día, con la masificación de dispositivos de posicionamiento como el

de una red social como el sitio web de Foursquare. 1 Un usuario se registra

12.2 Temporal Tipos

En lo que sigue, se supone que la dimensión de tiempo representa un

2012-01- 2012-04-01 2012-07-01 2012-10-01 2013-01-01 2013-04-01

Los tipos temporales son funciones parciales, es decir, pueden estar

Cuadro 12.1 Clases de operaciones sobre tipos temporales

Los tipos temporales tienen un conjunto asociado de operaciones, que se

2013-01-01) y 20,30. Explicaremos la operación Trayectoria cuando

Para ejemplo, Derivative (SalaryJohn) da como resultado un real temporal

A partir de estas operaciones, se pueden definir otras operaciones

2012-01- 2012-04-01 2012-07-01 2012-10-01 2013-01-01 2013-04-01

Figura 12.2 Representación gráfica del promedio temporal

12.2.1 Tipos espaciales temporales

Figura 12.3 Representación gráfica de las trayectorias de dos camiones

La operación Trayectoria proyecta geometrías temporales en el plano

Las operaciones topológicas también se pueden levantar. En este caso, la

El término Buffer (RouteT1, 0.6, 0:10) de ﬁ ne un cilindro elíptico, o

′ Fdistancia(F (t + δ), f (t)) .

Fdirecció n(F (t + δ), f (t)) .

Finalmente, Derivative devuelve la derivada del movimiento como un real

12.2.2 Temporal Tipos de campo

Figura 12.5 Tres posibles formas de conceptualizar los campos temporales

un valor de tipo temporal (campo (real)), que de ﬁ ne una función f: instant

12.3 Implementación de tipos temporales en PostGIS

Los DBMS actuales no admiten tipos temporales. Algunos prototipos

Cabe señalar que el soporte temporal se ha introducido en el estándar

Se puede insertar una tupla en esta tabla de la siguiente manera:

El valor de SalaryHist anterior corresponde al valor superior que se

Mostramos a continuación cómo algunas de las operaciones para tipos

devuelve, respectivamente, la matriz de períodos PERIOD ('2012-01-01',