Bases de Datos en Computación ó ilMóvil

Curso 2010/2011

Sergio Ilarri Artigas

Infraestructura InalámbricaÁrea de coberturaDispositivo

móvilDispositivo

móvil

EstaciónMáquina

Dispositivo móvil

Má iEstación base

Máquina fija

Dispositivo

Máquina fija

Estación base

Estación base

Red cableadaDispositivo

móvil

Dispositivo móvil

Área de coberturaMáquina fija

Máquina fija

Área de cobertura

Infraestructura Inalámbrica Red fija:

Fi d N t k (FN) Fixed Network (FN)

Estaciones Base: Base Station (BS) Base Station (BS)

Mobile Support Station (MSS)

Máquinas fijas: Máquinas fijas: Fixed Hosts (FH)

Dispositivos móviles:Dispositivos móviles: Mobile Host (MH) Mobile Unit (MU)

Celda / área de cobertura Handoff/handover

Redes Inalámbricas

Redes celulares Alto coste, escalabilidad limitada, ancho de banda

limitado (GSM: 9.6 kbps, GPRS: ≤ 170 kbps, UMTS 384 kbps 2 Mbps)UMTS: 384 kbps-2 Mbps)

LAN inalámbricas GPRS, UMTS, WiMax, UWB,

Bajo coste, 802.22g: ≤ 54 Mbps (22 Mbps), rango limitado (100-200 m)

é

, ,…

Servicios de satélite Amplia cobertura, muy caros,

b h d b d ( b )bajo ancho de banda (1-2Mbps)

…

Celdas o Áreas de Cobertura

Large cells.gLow density

Small cells.High density

Smaller cells.Higher densityHigher density

Vijay Kumar, “Mobile Database Systems”

Celdas o Áreas de Cobertura

El área de cobertura completa viene definida por un grupo de celdas

El tamaño de la celda depende de la El tamaño de la celda depende de la potencia de las estaciones base

PSTNMSC

Vijay Kumar, “Mobile Database Systems”

Handoff/Handover

Cambio de estación base debido al cambio de celda

Se transfiere cierta información (estado)

Soft handoff (≠ hardhandoff):handoff): Conexión temporal a 2

estaciones baseMargaret H. Dunham, ICDE’98 tutorial

Es necesario un mecanismo de seguimiento y gestión de posiciones

Dispositivos Móviles

1. Comunicaciones inalámbricas2. Desconexiones frecuentes (ej. ahorro

energía)3. Recursos limitados:

• Batería• Batería• Pantalla• CPU memoria• CPU, memoria

4. Se mueven → los recursos varíanS d l liSe pueden localizar

Dispositivos Móviles

Implicaciones del Entorno pMóvil

Bases de datos en computación móvil vs. Bases de datos distribuidas

Implicaciones: Implicaciones: Procesamiento de consultas

ó Gestión de transacciones Seguridadg Interfaces de Usuario

Procesamiento de Consultas (I)

Factores clave en la optimización de consultas: Ancho de banda disponible Coste económico de las transacciones / coste de

las comunicaciones Coste de establecimiento de una comunicación

Transacciones largas vs. cortas y frecuentes

C d í Consumo de energía: Minimizar la energía por transacción vs. maximizar el

número de transacciones por segundonúmero de transacciones por segundo

Procesamiento de Consultas (II)

Coste de las comunicaciones: Más costosas ($$, batería, tiempo) cuando hay

dispositivos móviles (fallos retransmisiones)ó é Comunicación asimétrica:

Recibir consume menos que transmitir (un orden de magnitud de diferencia)de diferencia)

El ancho de banda disponible para recepción es mayor La capacidad de bajada por petición será probablemente mayor

que la capacidad de bajada por cliente (menos peticiones)

Interés de la diseminación de datos en el medio i lá b i (b d ti )inalámbrico (broadcasting)

Posibilidad de comprimir los datos ( CPU)

Procesamiento de Consultas (III)

Respuestas aproximadas: Quasi-copies (desviación controlada)

quasicaching

Naturaleza de las consultas: Consultas dependientes de la localización

(localización, dirección, movimiento, contexto) Datos dependientes de la localización “Location transparency” vs. “location awareness”

Lenguajes de consulta e interfaces de usuariog j

Diseminación de Datos en un Entorno Inalámbrico (I)

Modo pull/on-demand: Consume energía Se compite con otros usuarios por el ancho de

banda

Modo push/broadcast: El servidor transmite por broadcast El cliente descarga los datos interesantes

EJEMPLO: el teletextotuning time buffer de páginastuning time buffer de páginasAlgunas páginas pueden diseminarse con másfrecuencia

Diseminación de Datos en un Entorno Inalámbrico (II)

Ventajas del modo push/broadcast: Posibilidad de transmitir ítems de datos

relevantes (“hot data”) a un gran número ( ) gde usuarios con el mismo coste ( escalabilidad)( )

Elimina la necesidad de enviar peticiones desde los dispositivos móvilesdesde los dispositivos móviles Conserva el ancho de banda Reduce el consumo de energía en los Reduce el consumo de energía en los

dispositivos

Diseminación de Datos en un Entorno Inalámbrico (III)

Desventajas del modo push/broadcast : Se incrementa la latencia de acceso Muchos ítems de datos posibles difícil Muchos ítems de datos posibles, difícil

adaptación a los intereses de cierto usuario Ningún programa de broadcast satisfará a cada Ningún programa de broadcast satisfará a cada

cliente individual (se considera el usuario “medio”) Optimizaciones de los clientes: ) pcaching (≠ replicación) y prebúsqueda

En algunos casos, simplemente no es posible (por ejemplo, monitorización de objetos móviles) diseminar todas las posibles respuestas

Diseminación de Datos en un Entorno Inalámbrico (IV)

Modelo híbrido (vs. de sólo lectura): Push+Pull (Interleaved Push and Pull, IPP) Peticiones relacionadas con los ítems transmitidos

Ej. Información entradas evento + compra de entradas

Peticiones sobre otros ítems de datosProblemade definir

Decisiones periódicas respecto a si seguir diseminando cierta información (y su frecuencia) o hacerla disponible sólo bajo demanda (ej

la relevancia(estimar lasnecesidadesd l hacerla disponible sólo bajo demanda (ej.,

dependiendo de las peticiones) Modelo suscripción: perfiles/consultas continuas

de los usuarios)

Modelo suscripción: perfiles/consultas continuas A veces no es posible (ej., trans. satélite)

Diseminación de Datos en un Entorno Inalámbrico (V)

Tres canales lógicos: Canal de datos de broadcast (downlink) Canal de datos solicitados bajo demanda Canal de datos solicitados bajo demanda

(downlink)Canal de peticiones de usuario (uplink) Canal de peticiones de usuario (uplink)

El ancho de banda disponible hay que repartirlo entre los distintos canales Si asignamos todo a los canales bajo Si asignamos todo a los canales bajo

demanda puede sufrir la escalabilidad

Diseminación de Datos en un Entorno Inalámbrico (VI)

Si todos los ítems de datos (n) se publican en el l d b d t l i f i (fl tcanal de broadcast con la misma frecuencia (flat

program):Ti di d /2 ít Tiempo medio de espera: n/2 ítems

Proporcional al número total de ítems de datosI d di d l ú d li Independiente del número de clientes

El mismo para todos los ítems de datosí Tiempos de acceso mínimos frecuencias de

broadcast distintas para los ítems en función de l id d ( á i l t i itid )su popularidad (o máxima latencia permitida)

predecir las necesidades de los clientes

Diseminación de Datos en un Entorno Inalámbrico (VII)

En general, tenemos dos problemas: Decidir qué items diseminar Decidir con qué frecuencia hacerlo

Envío de datos periódico (vs. aperiódico) Broadcast disk scheduling Broadcast disk scheduling

Visualiza el canal de broadcast como un conjunto de discos “en el aire” (de acceso secuencial)( )

Los discos giran a distinta velocidad: Mayor popularidad/importancia/relevancia de Mayor popularidad/importancia/relevancia de

los datos mayor velocidad de giro Otra forma de verlo: jerarquía de memoria

Diseminación de Datos en un Entorno Inalámbrico (VIII)

Si los datos se diseminan sin ninguna información adicional: Los clientes tienen que escuchar el canal Los clientes tienen que escuchar el canal

continuamente: consumo de energíaTuning time vs latency Tuning time vs. latency

Por tanto, es interesante proporcionar al cliente un directorio de los datos transmitidos (“index on the air”)( ) Doze mode vs. active mode

Diseminación de Datos en un Entorno Inalámbrico (IX) ¿Qué contiene el índice?

Di i t l Direcciones temporales Necesidad de cierta sincronización (el cliente puede escuchar

un poco antes, por seguridad)

Direcciones multicast La tarjeta Ethernet escucha esas direcciones mientras la CPU

está dormidaestá dormida

¿Cómo multiplexamos índice y datos? Una opción es transmitir el índice completo con cada ciclo de p p

broadcast Pero entonces los clientes que pierdan el índice tendrán que

esperar al siguiente ciclo: latenciaesperar al siguiente ciclo: latencia Para minimizar la latencia (de acceso al índice) es mejor

transmitir el índice varias veces

Diseminación de Datos en un Entorno Inalámbrico (X)

Indexing on Air: (1, m) indexing Se transmite el índice completo m veces

durante un ciclo de broadcast tuning time latencia

¿Es necesario trasmitir el índice completo cada vez?

latenciaDistributed indexing(sólo lo relevante paral d i )los datos que vienen)

Diseminación de Datos en un Entorno Inalámbrico (XI)

Distributed indexing: Mejor latencia y tuning time

Diseminación de Datos en un Entorno Inalámbrico (XII)

Otras estructuras de indexación: Basada en árbol Basada en dispersión Basada en dispersión …

Caching de Datos

Problemas de caching: ¿Qué pasa si cambian los datos recibidos? Se necesitan mensajes de invalidación Se necesitan mensajes de invalidación

(Invalidation Reports, IR) Ej identificadores de los ítems que han Ej., identificadores de los ítems que han

cambiado

Otra posibilidad: quasi-copias (quasicaching) Otra posibilidad: quasi-copias (quasicaching) Reconexión de clientes desconectados

D t l h Descartar la cache Preguntar al servidor grupos de ítems

Probabilidad de“falsos negativos”

Gestión de Transacciones (I)

Transacción móvil: transacción en la que hay óal menos un dispositivo móvil implicado

Más compleja que en las BDs distribuidas Distintos tipos de actividades transaccionales Transacciones largas Transacciones largas

Long-Live Transactions (LLT)Mantienen recursos durante periodos largos Mantienen recursos durante periodos largos

Ej.: proces. de reclamaciones en una compañía de seguros colección de estadísticas sobre una BDseguros, colección de estadísticas sobre una BD completa, proces. de balances en un banco, etc.

Gestión de Transacciones (II)

Sagas: LLT expresada como una secuencia de

transacciones que pueden entrelazarse con q potras

El SGBD garantiza que todas las El SGBD garantiza que todas las transacciones de la saga se ejecutan con éxito o si no se ejecutan transaccioneséxito o, si no, se ejecutan transacciones compensatorias para deshacer los efectos de ejecuciones parcialesde ejecuciones parciales

Gestión de Transacciones (III) Dos grupos de soluciones propuestas:

1) A éll j t l t i1) Aquéllas que ejecutan las transacciones parcialmente o completamente en los dispositivos móviles (autonomía y datos del disp móvil)móviles (autonomía y datos del disp. móvil) Punto crítico: soporte de propiedades ACID

Dificultad de garantizarlas debido a la Dificultad de garantizarlas debido a la autonomía necesaria para trabajar en modo desconectado (o débilmente conectado) y la ( ) ymovilidad de los dispositivos diferentes modelos de transacciones que las relajan

Estrategias de reconciliación para integrar el trabajo realizado localmente

Gestión de Transacciones (IV) Dos grupos de soluciones propuestas:

2) A éll d d l t i li it d2) Aquéllas donde las transacciones solicitadas por los dispositivos móviles se ejecutan en la red fija (una forma de “query shipping”)(una forma de query shipping ) Las propiedades ACID no están en peligro

Punto crítico: permitir movimientos del Punto crítico: permitir movimientos del dispositivo durante la transacción

Gestión de Transacciones (V)

Repaso de las propiedades ACID: Atomicity: todo o nada commit protocols Consistency: mantenimiento de las Consistency: mantenimiento de las

restricciones de integridadIsolation: cada transacción está aislada Isolation: cada transacción está aislada, incluso si hay concurrencia protocolos de control de concurrenciade control de concurrencia

Durability: los efectos de una transacción t l ison permanentes logging

Gestión de Transacciones (VI)

Gestión de desconexiones: Desconexiones predecibles/voluntarias:

Migración a un ordenador fijo:Migración a un ordenador fijo: De la ejecución de la transacción De los registros de log

Ejecución local tras descarga de datos remotos Anunciar la desconexión en el sistema

distribuido, si se está participando en algún protocolo distribuido

Gestión de Transacciones (VII)

Gestión de reconexiones: Transacciones locales en el dispositivo

pueden necesitar datos remotos para p pfinalizar

Transacciones remotas pueden necesitar Transacciones remotas pueden necesitar datos locales del dispositivoTransferencia de registros de log Transferencia de registros de log

Priorizar estas operaciones (duración li it d d l ió )limitada de la reconexión)

Gestión de Transacciones (VIII)

Inestabilidad de almacenamiento Caídas del dispositivo, robos, pérdidas, etc. Mantener datos en los ordenadores fijos, siempre

que sea posible: Transferencia de registros de log

Replicación de logs Replicación de logs Home BS logging, Home MH logging, Local BS logging

Importancia del coste de las comunicaciones Importancia del coste de las comunicaciones (importancia de confiar en la red fija)

Seguridad Problemas típicos que aparecen en redes

inalámbricas y computación móvil:inalámbricas y computación móvil: Los dispositivos aparecen y desaparecen Riesgo de robo de identidad Riesgo de robo de identidad Los datos comunicados pueden ser escuchados por terceros Consumo de recursos (ej., ancho de banda… ¿y quizá

también CPU y espacio de almacenamiento?) en una red foránea Monitorización y “contabilidad” del uso de recursosMonitorización y contabilidad del uso de recursos

Mecanismos de confianza: Compartición de recursos

“ d ” d f á “Invitados” en una red foránea

Interface de Usuario (I)

Características a considerar: Tamaño de pantalla reducido Teclado inexistente (virtual o de tamaño Teclado inexistente (virtual o de tamaño

reducido)

No muy apropiado para escribir SQL No muy apropiado para escribir SQL… Es necesario minimizar la entrada de texto Uso de puntero o pantalla táctil Representación con iconos y selección de Representación con iconos y selección de

alternativas

Interface de Usuario (II)

Ejemplo: HanDBase PalmOS PocketPC

http://www.ddhsoftware.com/handbase.html

Interface de Usuario (III)

Ejemplo: Mobile Database Viewer Plus

http://www.cellica.com/

Interface de Usuario (III)

Ejemplo: Mobile Database Viewer Plus

http://www.cellica.com/

Interface de Usuario (III)

Ejemplo: Mobile Database Viewer Plus

http://www.cellica.com/

Interface de Usuario (III)

Ejemplo: Mobile Database Viewer Plus

http://www.cellica.com/

Interface de Usuario (III)

Ejemplo: Mobile Database Viewer Plus

http://www.cellica.com/

Interface de Usuario (IV)

Ejemplo: Vieka eSQL

http://vieka.com/

Interface de Usuario (V)

Otros ejemplos: UltraLite (Sybase) DB2 Everyplace (IBM) DB2 Everyplace (IBM) Oracle9i Lite (Oracle)

JD t St (B l d) JDataStore (Borland) …

Arquitectura Básica de BDs de qLocalizaciones (I)

Objetivo: Mantener las posiciones de los usuarios a

nivel de red (celda)( )

Normalmente se utilizan aproximaciones basadas en particiones:basadas en particiones: Cada BD almacena las localizaciones de los

áobjetos localizados en cierta área Ej., cada estación base los objetos de su celda

Arquitectura Básica de BDs de qLocalizaciones (II)

1. Esquemas de dos niveles: HLR = Home Location Register

Base de datos “home” predefinida asociada a cada i ó ilusuario móvil

Mantiene la localización actual del usuario como parte del perfil de usuariop

VLRs = Visitor Location Registers Un VLR está a cargo de cada zona y contiene copias de

los perfiles de los usuarios visitantes El VLR local se contacta primero, si falla entonces se

contacta con el HLRcontacta con el HLR

Arquitectura Básica de BDs de qLocalizaciones (III)

1. Esquemas de dos niveles: Problemas:

El HLR es fijo, incluso para objetos que seEl HLR es fijo, incluso para objetos que se mueven permanentemente a otras áreas

No escala bien en sistemas distribuidos altamente dinámicos El HLR puede estar lejos. Esto afecta a las consultas

l HLR t bié l t li i dal HLR y también a las actualizaciones cada vez que el objeto en cuestión cambia de celda.

Arquitectura Básica de BDs de qLocalizaciones (IV)

2. Esquemas jerárquicos: Una BD de localización en una hoja

mantiene la localización de los usuarios en esa celda

Una BD de localización en un nodo Una BD de localización en un nodo intermedio mantiene la información de los usuarios localizados en su subárbolusuarios localizados en su subárbol Esta información es la localización o un puntero

a una entrada de nivel inferiora una entrada de nivel inferior

Arquitectura Básica de BDs de qLocalizaciones (V)

2. Esquemas jerárquicos: Si todos los nodos intermedios mantienen

apuntadores hacia niveles inferiores, la p ,búsqueda de un usuario empieza de abajo arriba y luego va de arriba abajoy g j

Si los nodos intermedios mantienen la posición exacta se ahorra el camino deposición exacta, se ahorra el camino de arriba abajo pero mayor coste de actualizaciónactualización

Arquitectura Básica de BDs de qLocalizaciones (VI)

2. Esquemas jerárquicos:

Extraído de:“Locating Objects in Mobile Computing”E. Pitoura, G. Samaras

Arquitectura Básica de BDs de qLocalizaciones (VII)

2. Esquemas jerárquicos: Reducen el coste de comunicación cuando

afecta a zonas cercanas En lugar de contactar con el HLR, que puede

estar lejos, se contactan BDs cercanasj ,

Sin embargo, el número de BDs de localizaciones a consultar y actualizar crecelocalizaciones a consultar y actualizar crece

La carga y requerimientos de almacenamiento crece en los nivelesalmacenamiento crece en los niveles superiores

Arquitectura Básica de BDs de qLocalizaciones (VIII)

3. Esquemas híbridos: Mantiene entradas de localización sólo en

nodos seleccionados de la jerarquía, y usa j q , ytambién HLRs

Camino de subida: de la celda del origen Camino de subida: de la celda del origen hasta el nodo ancestro común, de origen y HLR del receptor más cercanoHLR del receptor, más cercano

Camino de bajada: hasta el HLREl i i t i t El camino se interrumpe si se encuentra una localización directa

Arquitectura Básica de BDs de qLocalizaciones (IX)

4. Otras aproximaciones: Directorios regionales:

En este caso, no se utiliza un árbolEn este caso, no se utiliza un árbol

Arquitectura Básica de BDs de qLocalizaciones (X)

4. Otras aproximaciones: Base de datos centralizada:

Todas las localizaciones están en un nodo central Solución no escalable:

Búsqueda remota para cada llamada Actualización remota para cada cambio de celda Actualización remota para cada cambio de celda

El uso de una única BD podría llegar a ser aceptable en algunos casos muy específicosp g y p

Ej.: para mantener la localización de los camiones de una empresa, la localización de los taxis de una compañía, etc.

Arquitectura Básica de BDs de qLocalizaciones (XI)

4. Otras aproximaciones: Aproximación completamente replicada:

Todas las estaciones base mantienen todas lasTodas las estaciones base mantienen todas las localizaciones

Gran coste para actualizarlas todasp En consecuencia, no se adopta esta

aproximación

Arquitectura Básica de BDs de qLocalizaciones (XII)

Coste de búsqueda vs. coste de actualización:

¿En qué nodos se deberían mantener entradas qde localización?

¿Qué grado de replicación es aconsejable? ¿Qué resolución de localización se debe

adoptar? ¿Es interesante utilizar caches en los nodos?

(eager caching, lazy caching) Importancia del Call to Mobility Ratio (CMR)

Arquitectura Básica de BDs de qLocalizaciones (XIII)

La resolución de localización precisa (celda o GPS, por ejemplo) es un factor importante a tener en cuenta y puedeimportante a tener en cuenta y puede llevar a la necesidad de BDs especializadas:especializadas: Bases de Datos de Objetos Móviles

(M i Obj t D t b MOD)(Moving Object Databases, MOD)

Bases de Datos de Objetos jMóviles (I)

Son BDs especializadas en almacenar de forma eficiente posiciones de objetos móviles y procesar consultas sobre ellasmóviles y procesar consultas sobre ellas

MODGIS

SGBD

Base para el desarrollo de servicios b d l l li ió (LBS)basados en la localización (LBS)

Bases de Datos de Objetos jMóviles (II)

Gestión de localizaciones geográficas vs. gestión de localizaciones a nivel de red (ej. en una red celular, cell-id)red (ej. en una red celular, cell id)

Solución trivial – T1: (id-obj, x, y)l bl Poco escalable

Actualizaciones continuas Preguntas continuas reevaluadas

constantemente

No permite preguntar por situaciones futuras

Bases de Datos de Objetos jMóviles (III)

Una mejora – T2: (id-obj, L), L = atributo de localización Si id-obj es estático: L = (L x L y) Si id obj es estático: L = (L.x, L.y) Si id-obj es dinámico, el atributo debería

ser también dinámicoser también dinámico El valor de un atributo dinámico depende de t

S b t ib t L l L d t ti L f ti Subatributos: L.value, L.updatetime, L.function En el instante A.updatetime vale A.value

E l i t t A d t ti t l A l En el instante A.updatetime + t vale A.value + A.function(t)

Bases de Datos de Objetos jMóviles (IV)

Una mejora – T2: Ejemplo:

Si X.POSITION.function = 5 * t, se trata de unSi X.POSITION.function 5 t, se trata de un objeto cuya velocidad en el eje X es 5

A.updatetime: Transaction vs. valid time A.updatetime: Transaction vs. valid time Cuando se consulta un atributo dinámico,

el valor devuelto por la BD es elel valor devuelto por la BD es el correspondiente a ese instante de tiempo

La respuesta a una consulta puede variar en la La respuesta a una consulta puede variar en la ausencia de actualizaciones explícitas

Bases de Datos de Objetos jMóviles (V)

Una mejora – T2: En este contexto nos interesan atributos

dinámicos que representan coordenadas q pespaciales, pero puede haber otros Consumo de gasolinaConsumo de gasolina Temperatura Condiciones meteorológicas Condiciones meteorológicas …

Bases de Datos de Objetos jMóviles (VI)

Otra solución – T3: (id-obj, L), L = atributo de localización Si id-obj es estático: L = (L x L y) Si id obj es estático: L = (L.x, L.y) Si id-obj es dinámico:

L route (puntero a un objeto espacial de tipo línea) L.route (puntero a un objeto espacial de tipo línea) L.startlocation L.starttime (instante de la última actualización)( ) L.direction (0 ó 1) L.speed (función de t desde L.starttime o cte.) L.uncertainty (umbral en la desviación de la localización,

función de t desde L.starttime o cte.)desviación > L.uncertainty

actualizar

Bases de Datos de Objetos jMóviles (VII)

Otra solución – T3: Posición de un objeto:

En el instante L.starttime L.startlocationEn el instante L.starttime L.startlocation En el instante L.starttime + t (x, y) tal que

route-distance((x, y), L.startlocation) = L.speed (( , y), ) p* t En este caso, la respuesta debe incluir también el

l d l i tid b l i t t L t ttivalor de la incertidumbre para el instante L.starttime + t

Bases de Datos de Objetos jMóviles (VIII)

Otra solución – T4: El atributo dinámico es una polilínea que

representa la trayectoria del objetop y j Construcción basada en puntos GPS

(x1 y1 t1) (x2 y2 t2)(x1,y1,t1), (x2,y2,t2),… Para objetos que se mueven en redes de

carreteras utilización de un mapacarreteras, utilización de un mapa

Bases de Datos de Objetos jMóviles (IX)

Tiempo

Trayectoria 3DInstante actual

Trayectoria 3D

X

Ruta 2D

YAdaptado de transparencias de Ouri Wolfson

Bases de Datos de Objetos jMóviles (X)

Otra solución – T4: Construcción de una trayectoria pasada:

Encontrar el camino más corto entre dosEncontrar el camino más corto entre dos puntos

Construcción de una trayectoria futura: Construcción de una trayectoria futura: Comunicar al servidor la localización e instante

de salida y los destinos a visitary El servidor obtiene el camino más corto en un

mapa Convierte la ruta en una trayectoria

incorporando el tiempo

Bases de Datos de Objetos jMóviles (XI)

Otra solución – T4: Permite consultas futuras:

¿Dónde estará el objeto X dentro de 10¿Dónde estará el objeto X dentro de 10 minutos?

¿Cuáles son los objetos que estarán en esta j qárea dentro de 10 minutos?

…

Pero la trayectoria puede cambiar…

Bases de Datos de Objetos jMóviles (XII)

Instante actualTrayectoria 3D

XX

YRuta 2D

Tráfico pesado Adaptado de transparencias de Ouri Wolfson

Bases de Datos de Objetos jMóviles (XIII)

Incertidumbre - un objeto móvil debe actualizar su posición en la BD: La desviación que calcula excede el umbral La desviación que calcula excede el umbral

comunicadoCambia su ruta o dirección Cambia su ruta o dirección

Periódicamente … Varias políticas de actualizaciónp

Bases de Datos de Objetos jMóviles (XIV)

Ejemplos de políticas de actualización: Speed-dead reckoning (sdr)

Actualizar la localización y velocidad cuando seActualizar la localización y velocidad cuando se excede el umbral de incertidumbre permitido

Adaptive dead reckoning (adr) Adaptive dead reckoning (adr) El umbral de incertidumbre lo puede cambiar el

objeto como parte de la actualización, a fin de j p ,minimizar el coste de información por unidad de tiempo

Bases de Datos de Objetos jMóviles (XV)

Ejemplos de políticas de actualización: Disconnection detection dead reckoning

policy (dtdr)p y ( ) El objeto móvil establece el valor de

L.uncertainty como un valor decreciente, de y ,modo que con el tiempo se incrementa la probabilidad de que se necesite actualizar la l li iólocalización

Si ha pasado mucho tiempo desde la última actualización es muy probable que el objetoactualización, es muy probable que el objeto esté “desconectado”

Bases de Datos de Objetos jMóviles (XVI)

Se han propuesto distintos lenguajes de consultas. Ej.: Relational-oriented Relational oriented Moving Objects Algebra

F t T l L Future Temporal Language Constraint Query Language

Bases de Datos de Objetos jMóviles (XVII) Tipos de consultas:

Instantáneas: Ej.: moteles a 5 Km de mi posición

Continuas: Ej.: monitorizar los taxis cercanos

Persistentes: Consideran también la historia pasada Ej.: vehículos que incrementan su velocidad

O l f Otras clasificaciones Según el instante: futuras, históricas, presentes Según el propósito …

Bases de Datos de Objetos jMóviles (XVIII)

00c5c1

R1

00

R2 p3c6

A

Sr1

c2c0

c4 0p1 p4 s2

p2

c2c3

s3 r2s6

s5r2

s1s4

Bases de Datos de Objetos jMóviles (XIX)

Ejemplos:

SELECT oSELECT oFROM MOVING-OBJECTSWHERE I id ( P)WHERE Inside (o, P)

P

Adaptado de transparencias de Ouri Wolfson

Bases de Datos de Objetos jMóviles (XX)

Ejemplos:

SELECT oSELECT oFROM MOVING-OBJECTSWHERE P ibl /D fi it l I id ( P)WHERE Possibly/Definitely Inside (o, P)

Pdefinitely

possibly

incertidumbreAdaptado de transparencias de Ouri Wolfson

Bases de Datos de Objetos jMóviles (XXI)

Ejemplos:

SELECT oSELECT oFROM MOVING-OBJECTSWHERE S ti /Al (10 11)WHERE Sometime/Always(10,11)

inside (o, P)

Psometime l

10 1110 11sometime always

Adaptado de transparencias de Ouri Wolfson

Bases de Datos de Objetos jMóviles (XXII)

Consultas probabilistas: Ej.:

SELECT oFROM MOVING OBJECTSFROM MOVING-OBJECTSWHERE Inside(o, R)

Respuesta: (car12, 0.53)

(car18, 0.85)

Bases de Datos de Objetos jMóviles (XXIII)

Otros temas: Procesamiento de consultas Arquitecturas distribuidas Arquitecturas distribuidas Indexación de objetos móviles

E l ió (b h ki ) Evaluación (benchmarking) Privacidad Predicción de localizaciones Reducción de datos de localización Reducción de datos de localización Joins y minería de datos