How Trajectory Data Modeling Improves Decision Making?

Noura Azaiez and Jalel Akaichi

Department of Computer Science, ISG-University of Tunis, Le Bardo, Tunisia

Keywords: Trajectory Data, Trajectory Data Source, Modeling, Trajectory Data Mart, Bottom-up Approach.

Abstract: The incredible progress witnessed in geographic information and pervasive systems equipped with position-

ing technologies have motivated the evolving of classic data towards mobility or trajectory data resulting

from moving objects’ displacements and activities. Provided trajectory data have to be extracted, trans-

formed and loaded into a data warehouse for analysis and/or mining purposes; however, this later, qualified

as traditional, is poorly suited to handle spatio-temporal data features and to exploit them, efficiently, for

decision making tasks related to mobility issues. Because of this mismatch, we propose a bottom-up ap-

proach which offers the possibility to model and analyse the trajectories of moving object activities in order

to improve decision making tasks by extracting pertinent knowledge and guaranteeing the coherence of pro-

vided analysis results at the lowest cost and time consuming. We illustrate our approach through a creamery

trajectory decision support system.

1 INTRODUCTION

The integration of the mobility notion into the pro-

fessional life is among keys that can raise organiza-

tions toward success and guarantee its durability

since it offers the possibility of reducing services

geographical disparities. Thus, it becomes possible

to generate a large volume of Trajectory Data (TD)

that reflect the movements and stops of the mobile

objects in the real world. All provided TD are stored

into a data model named Trajectory Data Source

(TDSrc) model. However, the operational data

sources are poorly suited to long-term vision and

therefore seem inadequate for decision making.

Towards this inadequacy, we propose an approach

that offers the possibility to easily analyze trajecto-

ries of the moving objects in order to extract perti-

nent knowledge and guarantee the provided analysis

results’ coherence at the lowest cost and time con-

suming. We take as example the milk transfer to

creameries; milk producers are asked to transfer the

milk to a given creamery in a limited time while

keeping its preservation; what is a little difficult for

some producers given the large path between the

center of collecting raw milk (creamery) and produc-

tive farms. In order to facilitate the process of the

milk transfer to creameries, mobile cisterns was

appeared. Those latter move towards a set of desig-

nated farms to collect raw milk and therefore to

reduce the milk collection costs for producers.

In this paper, we discuss two important issues:

the first one focuses on how to integrate TD in or-

ganization Information Systems (IS); the second

issue expresses how can we rely on the bottom-up

approach, which results the generation of Trajectory

Data Marts (TDMs) or Trajectory Star Schemas

(TSSs) directly from TDSrc, at the aim to analyze

trajectories achieved by Mobile Milk Cistern for

collecting raw milk, discover localizations that pro-

vide the best milk quality and therefore the main

factors which are responsible for it.

To reach goals scheduled above, we propose to

organize this paper as follow. Section 2 presents an

overview concerning the problem of moving objects

trajectories’ modeling. In section 3, we discuss relat-

ed works. Section 4 expresses our position. In sec-

tion 5, we propose a logical model that gathers TD

provided from milk mobile cisterns’ trajectories.

Section 6 describes our proposed approach steps.

We conclude the paper in section 7.

2 STATE OF THE ART

Mobile objects are characterized with their different

movements and positions into a time interval. These

various positions describe the mobile object behav-

Azaiez N. and Akaichi J..

How Trajectory Data Modeling Improves Decision Making?.

DOI: 10.5220/0005558300870092

In Proceedings of the 10th International Conference on Software Engineering and Applications (ICSOFT-EA-2015), pages 87-92

ISBN: 978-989-758-114-4

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

ior changes and therefore its trajectories. In the liter-

ature, a great interest is expressed in the manage-

ment of moving objects. Some works are interested

only into the operational IS modeling (Spaccapietra

et al., 2007). While databases models are not suita-

ble to describe the multidimensional aspects, multi-

ple works are interested in the multidimensional

modeling of mobile objects behaviour.

In the literature, there are three approaches lead-

ing to store data in a Data Warehouse (DW); the top

down approach (Tryfona et al., 1999), the bottom up

approach (Kimball et al., 1998) and the middle out

approach (Sapia et al., 1998).

To the best of our knowledge, approaches that

are proposed to investigate the problem of Trajecto-

ry Data Warehouse (TDW) modeling are based only

on the top-down approach.

Marketos et al. (2008) dealt with the problem of

TDW building. Indeed, they proposed a framework

for TDW that takes into consideration the complete

flow of tasks required during a TDW development.

In fact, the first step consists to apply the trajectory

reconstruction process on the raw time-stamped

location data in order to generate trajectories. The

second step relies on the Extract-Transform-Load

(ETL) process that has to plays its important role in

order to feed Trajectory Data Cube. To achieve this

goal, authors proposed two alternative solutions: a

(index based) cell-oriented and a (non-index-based)

trajectory oriented ETL process. The final step of-

fers OLAP capabilities over the aggregated infor-

mation contained in the trajectory cube model. Au-

thors evaluated the efficiency of the proposed solu-

tions by implementing the TDW architecture for a

real-world application; an e-Courier dataset.

Arfaoui et al. (2011) presented a trajectory mod-

el related to the displacement of the herd, which

allows building a DW containing trajectory data.

These later are generated following the monitoring

of herd movements. To achieve this, authors pro-

posed two models. The first one is based on the

Entity-Relation (ER) model which helps to visualize

the different entities corresponding to the trajectory

and its different components as well as the relation

that can exist between them. The second one is

based on the Spaccapietra model. Results show that

the second model is more efficient for generating a

TDW model since it puts into consideration spatial

and temporal aspects, which is neglected by the first

model.

Errajhi (2014) investigated the problem of TDW

modeling using a new method which is based on a

generic model that it could easily be adapted to any

domain. Their work shows the benefits of fuzzy

logic in solving the challenges related to TD by

integrating fuzzy concepts into the conceptual and

the logical model. Fuzzy sets provide mathematical

meanings to natural language and are therefore able

to handle the imprecision of the natural language.

For that, they integrated the fuzzy logic in the TDW

modeling. Then, authors’ work has been implement-

ed to ambulance management domain.

Leonardi (2014) presents a new approach that

aims at designing a TDW model, having the ability

to store and analyze trajectory data. Authors includ-

ed the spatial and temporal notions in dimensions.

Therefore, the framework collects streams of spatio-

temporal observations related to the position of mov-

ing objects; this presents the first task to reconstruct

TD. The next step presents the ETL phase where

such reconstructed trajectories will be used in order

to load the aggregated data into the proposed TDW.

Authors implemented T-WAREHOUSE, a system

that incorporates all the required steps for Visual

Trajectory Data Warehousing, from trajectory re-

construction and ETL processing to Visual OLAP

analysis on mobility data.

3 DISCUSSION

Following the study of a sample of works related to

the TDSrc and TDSS modeling, we present a com-

parative study based on weaknesses and strengths of

each research work.

As the “trajectory” term is a new concept, we

note that the researchers were interested in trajecto-

ries modelling in the first place. The work of (Spac-

capietra et al., 2007) is among works which tried to

solve the problem of TDSrc conceptual modelling.

Trajectories’ studies didn’t stop at this level. In fact,

the last work presents the basis of the work (Arfaoui

et al., 2011) where authors are concentrated on the

modelling of the animals’ trajectories. They pro-

posed two ways of trajectory data models to build a

TDW model allowing the storage of TD. The first

one is based on the ER model and the second is

based on the model of (Spaccapietra et al., 2007).

The new notion “fuzzy”, that is interposed in

(Errajhi 2014), gives another manner to study the

TDW modelling. This method gives a meaning to

TDWs when fuzzy data are involved and especially

when users want to ask questions in natural lan-

guage.

The main goal that gathers the majority of works

cited above is to model a generic TDW design that is

able to facilitate the decision-making in different

areas. To achieve this goal, we note that these works

ICSOFT-EA2015-10thInternationalConferenceonSoftwareEngineeringandApplications

proceeded the same classic strategy; they take the

top-down approach as the base of their works. This

later is designed using a normalized data mod-

el. Atomic data, that are data at the lowest level of

detail, are stored in a central repository TDW. Be-

sides, TDMs containing data needed for specific

business processes are created from TDW; this re-

quires the TDW whole conceptual modelling as a

first step; what costs expensive and therefore con-

flicts with the organization goal.

4 OUR POSITION

Analyzing TD requires their integration in the organ-

ization DSS. In order to guarantee the better decision

making, it’s important to choose the best strategy to

adopt for the TDSS modelling. As it’s cited in the

section above, there are three approaches leading to

storing data in a DW; the top down approach, the

bottom up approach and the middle out approach.

We compared these three approaches and we con-

clude that the bottom up approach is the most suita-

ble for designing a TDSS that analyses TD since it

presents the organization’s information consistently

and make data quickly and easily accessible; what is

the key of the organization success. Unlike the bot-

tom up approach, the top down approach is consid-

ered the heaviest one and the most expensive since it

requires the whole conceptual modeling of the

TDW. Besides, our TDSS modeling vision conflicts

with the principle of the middle out approach. In

fact, this latter involves, sometimes, cutting com-

promises that duplicate identical dimensions for

practical purposes; and this leads to the analysis

results disturbance.

Kimball is among authors that support the bot-

tom up approach principle. He stated that the DW is

nothing more than the union of all the DMs. In other

word, DMs are created providing thin views into the

organizational data then combined into a larger all-

encompassing DW. Kimball’s methodology consists

to i) select business process, ii) declare the grain, iii)

choose dimensions and iiii) identify facts. This

methodology leads to identify star schema elements

and therefore gives the birth of a set of DMs. How-

ever, these steps’ scheduling seems not effectively

adequate for TDMs building. In fact, identifying the

grain firstly, then dimensions and finally facts can

complex the process of building trajectory dimen-

sional star schemas.

For this, we propose an approach that investi-

gates the problem of TDSS modelling relying on the

Kimball’s philosophy but not Kimball’s design

steps. In fact, it’s more coherent to extract facts from

the TDSrc model and then to identify related dimen-

sions. Thus, it becomes easy to specify granularities

that can be hierarchies for these axes of subject

analysis. Our methodology consists to reverse the

DW design steps proposed by Kimball; this leads to

facilitate the TDMs holding.

In our example, all provided TD have to be ana-

lyzed in order to get knowledge about trajectories

that contains farms which product the high quality

raw milk conforming to a set of selected Norms

defined by the Big Creamery Manager and the pro-

ducer. This gives the possibility to discover the main

factors responsible for the milk quality such as the

grass localization that animals are alimented

from…To the best of our knowledge, no authors

have designed a TDSS relying on the bottom up

approach.

The following figure describes the global archi-

tecture of a creamery decision making system.

Figure 1: The creamery TDSS architecture.

5 TRAJECTORY DATA SOURCE

MODELING

In the midst of the technology progress, professional

success is no longer related only to the organization

winning strategies but also to its ability to integrate

new technologies that have become increasingly

spread in all areas. For example, using mobile de-

vices such as PDA to accomplish professional mis-

sions presents a good solution to send data concern-

ing moving objects activities in real time.

HowTrajectoryDataModelingImprovesDecisionMaking?

5.1 Mobile Milk Cistern Trajectory

Scenario

Creameries need regular intake of milk to ensure

continuity of the process of transformation. For that,

the transfer process is considered the most crucial

during the production cycle of creamery products

(cheese, yogurt ...). Therefore, this task’s fulfillment

requires the collaboration of the mission team mem-

bers. Starting with the mobile cistern driver, his role

is to drive according to a trajectory that is planned

by the head of the mission. In fact, each cistern has

its own trajectory, which is composed of a set of

movements and stops. It is the "movement" state

when the road traffics authorize the movement.

Otherwise, or if the cistern reaches a destination (a

farm) among planned destinations, it is in the "stop"

state. The different information concerning the posi-

tion of the mobile milk cistern are sent through wire-

less technology named GPS. This later is reliable to

specify exactly the position of the mobile milk cis-

tern.

The controller plays a very important role in the

milk collection process. His major task is to sample

the raw milk in a creamery production unit with

optimum technical and hygienic conditions. This

sample allows him to monitor the conditions in

which the raw milk is subjected in the farm (temper-

ature ...). Besides, the controller has to record, for

each farm, the volume of the collected milk, date

and time of loading the raw milk from the local

cistern to the mobile cistern. Thanks to the PDA

provided with the controller, data will be forwarded

easily to the Big Creamery Manager.

5.2 Mobile Milk Cistern Trajectory

Modeling

In this section, we focus on modeling the mobile

cistern trajectory. Figure 2 presents relational TDSrc

schema as a logical model.

Mobile_Milk_Cistern (id_MMC, #id_driver,

#id_controller)

Driver (id_driver, name_driv, address_driv,

phone_driv)

Trajectory (id_traj, #id_move, #id_stop,

#id_mobile_cistern)

Stop (id_stop, duration, #id_begin, #id_end,

#id_loc)

Move (id_move, duration, #id_begin, #id_end)

Location (id_loc, name)

Begin (id_begin, Begin_time)

End (id_end, End_time)

Controller (id_controller, name_cont, address_cont,

phone_cont, #id_PDA)

Milk_local_cistern_details (id_local_cistern,

volum, temperature, #id_farm, #id_controller)

Farm (id_farm, name, address, phone, #id_loc)

PDA (id_PDA, name)

GPS (id_GPS, name)

Big_creamery_manager

(id_Big_Creamery_Manager, name_BCM, ad-

dress_BCM, phone_BCM, #id_PDA)

Norms (id_Norm, #id_local_cistern,

#id_Big_creamery_manager, #id_controller,

Norm_Compatibility_mark)

Figure 2: TDSrc logical model.

6 TOWARDS TDM MODELING

Choosing to model a TDSS according to the princi-

ple of the bottom-up approach requires identifying

the star schema elements directly from the TDSrc

model. Collecting these elements leads to hold a set

of schemas called TDMs. Those later are designed to

serve a particular set of decisional analyses.

6.1 Star Schema Elements

Identification

DM architecture is offered for general business peo-

ple that need to move easily between marts in order

to extract knowledge. Our approach is composed of

three major steps for collecting the star schema ele-

ments. Firstly, we have to identify facts, then dimen-

sions and finally hierarchies.

 Step 1: Facts identification

Whatever the kind of DW, fact tables are the most

important elements constructing multidimensional

star schemas. Indeed, they record measures about

particular events that occur in the business. Our goal

is to propose a relevant rule that is able to extract

fact tables from the TDSrc model.

Rule1: In the TDSrc model, if a table T references

several tables but not referenced by any table, if T

contains one or several column(s) that are suscepti-

ble to be parameter(s) to calculate an additive col-

umn(s) that serves analysis and if the primary key of

T contains foreign key(s), then T can be a plausible

fact F.

 Step 2: Dimensions identification

In a DM, the role played by dimensions is not less

important than that played by facts. Indeed, dimen-

ICSOFT-EA2015-10thInternationalConferenceonSoftwareEngineeringandApplications

sions present axes of subject analysis. Their identifi-

cation directly from the TDSrc model is a step that

depends on the previous one since they serve to

increase the level of detail of the fact table. This

strong dependency facilitates the extraction of di-

mension tables from others.

Rule 2: If a table T is referenced by T

(table that

feeds a fact F), if T

is atomic and if T contains

columns that can be dimensional attributes (strong or

weak), then T feeds a new dimension D for F.

 Step 3: Hierarchies identification

Dimension Hierarchies are also essential compo-

nents. They are used to define data aggregation.

Hierarchies group levels from general to granular;

this is one of the key benefits of a DM since it ena-

bles analysts to access data quickly.

Rule 3: If a table T is referenced by table(s) that feed

dimension(s) D and if it doesn’t refer any table then

T can feed a new level of hierarchy in each of these

dimensions, the identifier of T will be a terminal

parameter in multiple hierarchies and textual attrib-

utes of T become a weak attributes for the added

level. Otherwise, if T refers other table T

in the

TDSrc model then the identifier of T becomes a

parameter inserted between the identifier of the

dimension D and the identifier T

6.2 Rules Results

Applying these rules on our TDSrc model example

leads to obtain a set of facts that present the analysis

subjects, dimensions which are the axes of the se-

lected subject analysis and hierarchies that are re-

sponsible to define data aggregation.

The first rule enumerates conditions that must

satisfy an existing table in the TDSrc model to feed

an analysis subject. In our example, the tables Tra-

jectory and Norms satisfy those conditions. Conse-

quently, they can be plausible facts. For the table

Norms, it contains a column

Norm_Compatibility_mark. This later verifies if the

milk quality provided in the farm respects such norm

defined by the farm producer and the big creamery

manager. The additive columns

Farm_compatibility_rate and the Farm_Rank can be

calculated in function of Norm_Compatibility_mark.

Concerning the table Trajectory, it contains columns

that can be parameters to calculate the number of

stops and moves and the duration of the full trajecto-

ry.

The tables Stop, Move, Controller,

Milk_local_cistern_details, Big_creamery-

_manager and Mobile_milk_cistern respect condi-

tions presented in the second rule; then, they feed

dimensions in TDMs.

The third rule presents conditions that must satis-

fy a table existing in the TDSrc model to feed a

hierarchy. In our example, the tables Begin, End,

PDA, GPS and Driver respect these conditions and

therefore they can feed hierarchies in the star sche-

ma. The table Farm is referenced by the table

Milk_local_cistern_details that feeds a dimension

and it refers the table Location. Consequently, the

identifier of the table Farm becomes a parameter

inserted between the identifier of the dimension

Milk_local_cistern_details and the identifier of

Location. Beside its role as a dimension in some

TDMs, the table Controller can play the role of a

hierarchy in others since it is referenced by a table

that feeds a fact (Norms) and another one that feeds

a dimension (Mobile_milk_cistern).

Arranging these elements according to a set of

rules gives the birth of what is called star schema

model.

6.3 Example of Mobile Milk Cistern

Trajectory Star Schemas

Following the identification of fact tables, dimen-

sions and hierarchies, it becomes possible to build a

set of TDMs which their composition is optimized

so that decision makers are able to look data in a

unique way and this guarantee analysis results co-

herence. In our example, the first TDM modeled in

figure 3 is extracted from our TDSrc model. It fo-

cuses on the norms compatibility analysis. This

TDM model offers the possibility to discover cream-

eries that respect Norms defined by the Big Cream-

ery Manager and the Milk Producer and therefore

localizations that provide the best milk quality.

Figure 3: Norms compatibility analysis.

Figure 4 present the second TDM example. It focus-

es on Mobile Milk Cistern trajectory analysis. The

HowTrajectoryDataModelingImprovesDecisionMaking?

main goal is to discover the principal factors respon-

sible for the milk quality, such as alimentation of

animals, weather...

Figure 4: Mobile Milk Cistern trajectory analysis.

Each TDM modeled directly from TDSrc model

focuses on a particular subject analysis. This leads to

queries results coherence and therefore knowledge

facility extraction. We approve that whatever the

DW kind including TDW, this later is the conglom-

erate of all TDMs that model organization business

events. Thence, once more than two TDMs are built,

the fusion of these later gives the birth of a central

repository of data named TDW. It’s a system that

collects TD organized around the organization major

issues; those issues are the same that pushed build-

ing TDMs as a first step.

7 CONCLUSIONS AND

PERSPECTIVE

In this paper, we presented an overview on the TDW

modeling problem. We exposed some solutions

proposed by different authors in recent years. Then,

we expected the absence of a TDSS modeling solu-

tion that really solves the problem of organization

decision making taking into account the facility that

must be offered to users to extract knowledge that

leads to the organization durability. Hence, we pro-

posed an approach which deals with the TDSS mod-

eling that is able to improve the strategy of the or-

ganization decision making. Our approach is based

on the bottom-up approach. It consists to give the

birth of a set of TDMs generated, directly, from a

TDSrc model. The fusion of these TDMs leads to

build the organization’s complete TDW.

As the operational trajectory database is scalable

due to data type and data sources heterogeneity,

TDSrc model evolve over time. This, obviously, has

a direct impact on TDSS. In fact, the propagation of

changes performed on TDSrc towards TDSS gives

the possibility to change TDMs’ structures, or even

to give the birth of new TDMs’ models that focus on

new subjects analysis, and therefore to alter the

existing TDW model. Although its cruciality, the

TDSS evolution problem hasn’t yet received the

interest that it deserves. Therefore, as perspective,

we propose to deal with this problem that’s still an

open research issue.

REFERENCES

Arfaoui, N., Akaichi, J., 2011. Modeling Herd Trajectory

Data Warehouse. International Journal of Engineering

Trends and Technology (pp. 57-71).

Errajhi, E., 2014. Trajectory data fuzzy modeling: ambu-

lances management use case. In International Journal

of Database Management Systems (IJDMS), Volume

6, (pp. 1-10).

Kimball, R., Reeves, L., Ross M., Thornthwaite, W., 1998.

The Data Warehouse Lifecycle Toolkit: Expert Meth-

ods for Designing, Developing and Deploying Data

Warehouses. The book, John Wiley and sons publish-

ing.

Leonardi, L., 2014. A Framework for Trajectory Data

Warehousing and Visual OLAP Analysis.In doctoral

thesis Ca’foscari university of Venice.

Marketos, G., Frentzos, E., Ntoutsi, I., Pelekis, N., Raffae-

tà, A., Theodoridis, Y., 2008. Building real-world tra-

jectory warehouses. In 7

International ACM Work-

shop on Data Engineering for Wireless and Mobile

Access(MobiDE), (pp. 8-15), Vancouver, BC, Canada.

Sapia, C., Blaschk,a M., Höfling, G., Dinter, B., 1998.

Extending the E/R Model for the multidimensional

paradigm. In Proceedings of International Workshop

on Data Warehousing and Data Mining, (pp 105-116),

Germany.

Spaccapietra, S., Parent, C., Damiani, M. L., de Macedo,

J. A., Porto, F., Vangenot, C., 2007. A Conceptual

View on Trajectories. Research Report. Ecole Poly-

technique Fédérale, Database Laboratory, Lausane,

Switzerland.

Tryfona, N., Busborg, F., Christiansen, J.G.B., 1999.

StarER: A Conceptual Model for Data Warehouse De-

sign. In Proceedings of the ACM 2nd International

Workshop on Data warehousing and OLAP, (pp 3-8)

Missouri, USA.

ICSOFT-EA2015-10thInternationalConferenceonSoftwareEngineeringandApplications