Smart-Approach Based Internet of Things and Skyline Query for Multicriteria Decisions for Travel Services

In this section, we first briefly present the purpose of using the cloud computing and business intelligence and present the purpose of using the cloud computing and business intelligence and analytics in this study. Then, we introduce the success of approaches based on the Internet of Things for reservations systems. Finally, we review related works for distributed databases applications by using skyline query approaches.

2.1 Business intelligence and analytics

Business intelligence and analytics (BI&A) has become a significant topic for many researchers and practitioners. This is attributed to the remarkable impact of data-related problems on the technologies, systems, practices, methodologies, and applications that analyze critical business data, and the inevitability of establishing new approaches and terms for solving problems in contemporary business organizations [2].

Over the years, a huge amount of historical data has been collected various types structured and unstructured data. Such data are crucial for small and large business organizations. Successful companies make strategic business decisions based on the analysis of such data. For further improvement, business organizations must implement integrated data management systems and use BI&A techniques. Big data analytics have several applications related to many academic and industrial fields [3].

2.2 Cloud computing

Cloud computing is a common solution for managing high-speed computing using large-scale databases. This revolutionary concept allows the enhanced use of distributed resources [4]. Moreover, the data -warehousing approach has currently become a popular and efficient solution that can improve decision-making in companies [5].

2.3 Smart-approach based Internet of Things for reservation systems

In an IoT architecture, sensors collect a wide variety of information from their closest environments. The gathered data are sent via gateways from objects (different devices) to the cloud and vice versa. The gateways enable data preprocessing and filtering before sending the data to the cloud. Such data may also be transferred to the cloud for detailed processing and storing. Furthermore, the gateways ensure the transit of the control commands from the cloud to the objects (things) [6]. Subsequently, actuators within these objects (things) execute these control commands [7]. The services provided by the IoT include booking services reliant on distributed and heterogeneous data, where the user seeks to obtain appropriate booking services in a reasonable time. Furthermore, scientific analysis is required for big businesses in this field to make strategic decisions, thereby improving the quality of services provided to the user.

Sagar et al. [8] proposed a vehicle-booking reservation system using IoT. They employed automatic car parking using a microcontroller and adopted the global system for mobile communications to monitor available space for booking via a mobile application.

2.4 Skyline query approaches for distributed databases applications

The skyline query [9] is a popular approach for minimizing the search space to select only few data objects exhibiting certain characteristics.

Let D be a d-dimensional database; d1, ..., dm denote the dimensions of the Skyline; for example, price, distance to the beach, rating, ect. A tuple p = (p1,...,pk, pk+1,...,pl, pl+1, ...,pm, pm+1,...,pn)dominates tuple q = (q1,...,qk, qk+1,...,ql, ql+1,...,qm, qm+1,...,qn) if p is not worse than q in any d dimension and p is better than q in no less than one d dimension. “The skyline query is defined as the process of recovering a set of points where each one is not dominated by another point [10]. It has been applied in several multicriteria-based decision-making applications. Search database systems [11] web service composition [12], and routing in wireless ad hoc networks [13] are examples of such applications.

Skyline queries have been used in many scenarios and configurations. For instance, a skyline query is usually used for handling large or anticorrelated datasets. Moreover, it can be used when the customer is keen to inspect a particular subspace rather than the entire data space or when the users or customers show interest in specific constraints. Each constraint is typically expressed as a range along a dimension of the dataset [14]. In a study by Borzsony et al. [9] the skyline operator in large-scale datasets offers three algorithms: block-nested-loops (BNL), divide-and-conquer, and B-tree-based schemes. Zaman and Morimoto [10] proposed area skyline query for selecting good locations in maps.

The dynamic skyline query [15, 16] is a type of query in which the coordinates of each point are given by a set of distance (dynamic) functions, which consider the distance between a given query/reference point q and a point p of the original dataset [14].

Zou et al. [17] derived a pruning rule that leverages graph properties to determine the candidates for the problem of dynamic skyline queries in a large graph (hereinafter, a DSG-query). To efficiently process a query, they used a filter-and-refine framework. They showed that the DSG-query is answered and short distances between the summits are computed in O(H). Here, H represents the number of maximal hops between any two summits.

Many methods have been developed for skyline-join queries in distributed and no distributed environments, where data are stored in multiple tables requiring the existence of join operations between them to compute the final skyline and then propose efficient approaches for sharing the join processing cost with the skyline computation cost [14]. For example, Vlachou et al. [18] SFSJ (Sort-First-Skyline-Join) can compute the correct skyline set by accessing only a subset of the input tuples, i.e., it exhibits the early termination property. It can be easily implemented in existing database systems, as it relies on a common infrastructure. However, this algorithm is not practical for complex database systems.

Sun et al. [19] proposed a distributed adaptation of SaLSa and an iterative algorithm to calculate the skyline join in a distributed manner. This algorithm is a hybrid of the skyline and joins operations. Raghavan and Rundensteiner [20] established a ProgXe framework for skyline join calculation. This framework supports progressive result generation. ProgXe divides the input relations using a multidimensional grid access approach. It transforms the execution of Multi Criteria Decision Support (MCDS) queries, comprising skyline over joins, to be non-blocking by progressively generating results early and often restricts the framework to joins using base tables; however, in practice, the join may also be calculated over complex relational expressions.

Jin et al. [21] described a skyline operator on multirotational tables. This operator combines a Trimerge join technique with skyline processing. Given A and B, two relations for computing the skyline over A >< B, where a one-to-many relationship exists between A and B such that the join operation is performed if A has a primary key corresponding to a foreign key in B. Further, the join operation on A and B with a many-to-many relationship can be solved by introducing a third table C that contains the attributes of B and the join attribute of A; then, a join between A and C and one between the resultant join and B can be performed.

Vlachou et al. [22] proposed an algorithm called SKYPEER in peer-to-peer networks, where the dataset is horizontally distributed across the peers. First, in a preprocessing phase each peer Pi computes the local ext-skyline of its dataset Si and sends it to the associated super-peer. The super-peer calculates its own ext-skyline, by merging the local skyline results. This result is a threshold value. In processing request the SKYPEER forwards the skyline query requests among peers according to local results.

Kalyvas et al. [23] used skyline queries and introduced the time factor in traditional skyline algorithms in temporal databases.

Zhang et al. [24] proposed a skyline join algorithm called Skyjog for two or more relations based on group division approach. For each relation, tuples are grouped according to the join attribute. This proposed algorithm divides the tuples into diverse partitions depending on the dominance relationships of inter-group and intra-group. The final result of Skyjog is the tuples generated by some join combinations to be skyline points.

Table 1. Comparison between different approaches

Amiruzzaman and Jamonnak [25] proposed web-based system focusing on customers’ stratification with used the multidimensional Skyline query. This system provides ranks of shopping malls based on customers’ preferences and helps to find best shopping malls based on users’ requirements.

In Table 1, we compare the presented related works of the multicriteria decision such that the comparison lines are skyline query type, data type and distributed architecture.

In brief, the previous studies on skyline were restricted to either single relation or multi-relations in distributed and no distributed environments. Moreover, these approaches did not consider the fact that IoT systems are naturally distributed. The present work focuses on exploiting the distributed nature of IoT to employ a local join dynamic skyline on the gateway level and then proceed to employ a global join dynamic skyline on the server level for a typical example (i.e., booking services). The main goal is to search and select the best available services considering users’ requests.

In this work, the skyline queries were used for tourism-condition search and selection of the best booking services. The proposed scheme achieves optimization of the time required to execute queries and reduces resource consumption, thereby improving the quality of decision-making. Further details of our proposed optimization are as presented below:

• The focus is on the dynamic skyline during user-based booking service selection to remove the no dynamic skyline booking services that are dominated by dynamic skyline booking services; in other words, dynamic skyline booking services have better user-based responses with respect to the users’ requests and the number of available booking services than no dynamic skyline booking services. The dynamic skyline returns the best services to answer the users.
• This work exploits the parallel nature of IoT architectures, wherein the architecture comprises distributed gateways in the network and is connected to a local server in cloud computing. Each local server manages the data of different travel services before locally responding to users’ requests. Thereafter, the global server implements a global dynamic skyline operator to gather the results of all local services; ultimately, the final answer is provided based on the client requirements.
• The server in this architecture is linked to a predefined database comprising services already customized based on the clients’ selections. This database is primarily used to analyze different requests related to tourism. This analysis effectively improves access to high-quality services and offers a considerable amount of tourism-service data in a short duration. Moreover, it creates and boosts competition among the businesses that offer similar services to meet the client requirements.

In this section, we discuss in detail the proposed approach for travel booking using skyline queries in an IoT environment.

4.1 Problem formulation

Let B be a set of booking services categorized as m services, B={B1, B2, B3, …, Bm}. Each service has a relation in the database. B1={h1, h2, h3, …., hn}∈B represents the relation of hotels, B2={a1, a2, a3, …, ak}∈B represents the relation of airplanes, and B3={r1, r2, r3, …, rd}∈B represents the relation of restaurants, etc. Each booking service type is classified into permanent services, which are effective throughout the period of travel, or temporary services, which are effective at a specific time during travel. The permanent services are annotated using the “+” sign (e.g., B+), whereas the temporary services are annotated using the “−” mark (e.g., B−).

Let C be a set of user conditions, where the common characteristics of travel services represent join attributes J between the relations; let d denote a dynamic scoring attribute between the relations. Let K be a set of numerical attributes in the schema of every relation, where K=("K1" ∪"K2" ∪"K3" ∪"..." ∪"Km" ).

For example, the number of services is m=3(R1=hotels, R2=planes, R3=restaurant), C={Travel_money, Location, start_date, date_retoure}; in this case J={Location, date_travel}, D={Travel_money}, K1={price, nb_star}, K2={price, class}, and K3={price, quality}.

4.1.1 Search space of the booking skyline query

For defining the search space of the LBS, we have a query <K, J, d> and let B be a table. We can define the search space of booking skyline BS by achieving the following conditions:

a) BS =B1⊳⊲B2⊳⊲"B3...Bm," B_i∈BS;

b) ∀att_i∈(k∪d)→∃B_i (B_i∈BS)∧(att_i∈B_i);

c) $\forall B_{i}\left(B_{i} \in \mathrm{BS}\right) \rightarrow \exists \mathrm{att}_{i}\left(\mathrm{att}_{i} \in B_{i}\right) \wedge\left(\right.$ att $_{i}=$ price $\left._{i}\right)$;

d) In this case, d is the total price of booking services. Hence, for the best search space, first, we define the travel time using variable t, where t = date_retoure − start_date; we use the variable t with the permanent services B+.

$\forall B_{i}^{+}\left(B_{i}^{+} \in \mathrm{BS}\right) \rightarrow \exists \mathrm{price}_{i}^{+}\left(\right.$price $\left._{i}^{+} \in B_{i}^{+}\right) \wedge$ (price $_{i}^{+}=$

price $_{i} \times t$ )

For temporary services B−, we use the following definition:

$\forall B_{i}^{-}\left(B_{i}^{-} \in \mathrm{BS}\right) \rightarrow \exists \operatorname{price}_{i}^{-}\left(\right.$price $\left._{i}^{-} \in B_{i}^{-}\right) \wedge$ (price $_{i}^{-}=$

price $\left._{i}\right)$

Then, we cannot determine BS and the total prices are less than or equal to the dynamic attribute:

$\sum_{i=1}^{m}$ price $_{i}^{+}+\sum_{i=1}^{m}$ price $_{i}^{-} \leq d$

e) BS’ that has two properties (described above) and fewer tables than BS cannot be found.

$\nexists \sum_{j=1}^{m}$ price $_{j}^{+}+\sum_{j=1}^{m}$ price $_{j}^{-} \leq \sum_{i=1}^{m}$ price $_{i}^{+}+$

$\sum_{i=1}^{m}$ price $_{i}^{-}, j \neq i$

f) The search space of the distributed booking skyline β for a query <K, J, d> is defined as follows:

$\beta=\mathrm{BS} 1 \cup \mathrm{BS} 2 \cup \mathrm{BS} 3 . . \cup \mathrm{BSn}, \mathrm{BS}_{i} \in \beta$

4.1.2 Local booking skyline domination

For a given booking skyline query <K, J, d> and its search space BS, assume t1 = (v0, v1, v2,..., vd) and t2 = (v’0, v’1, v’2,..., v’d) are two tuples of BS. t1 dominates t2 if

$\begin{aligned} \forall \mathrm{att}_{i}\left(\operatorname{att}_{i} \in K\right) \wedge\left(\operatorname{att}_{i}=\operatorname{price}_{i}\right) \rightarrow\left|d-\sum_{i=1}^{m} v_{i}\right| \\ & \prec\left|d-\sum_{i=1}^{m} v_{i}^{\prime}\right| \wedge \exists \mathrm{att}_{j}\left(\mathrm{att}_{j} \in k\right): \mathrm{v}_{j}^{\prime} \leq v_{j} \end{aligned}$

For clarity, we use ti <dom tj to indicate that the tuple ti booking skyline dominates tj and $\sum_{i=1}^{m}$ price $_{i} \prec_{d} \sum_{j=1}^{m}$ price $_{j}$ to indicate that ti booking skyline dominates tj in the sum of price services for d.

4.1.3 Global booking skyline domination

The global result set G for a booking skyline query Q = <K, J, d> in its search space β must have the following properties:

a) $\forall t_{i} \in G \rightarrow \exists t_{j}\left(t_{j} \in \beta\right) \wedge t_{j}>_{d o m} t_{i}$;

b) Suppose ti ∈G and ti = (v0, v1,..., vm); if atti∈K, vi must satisfy the corresponding conditions.

4.2 Booking skyline query

In this section, we propose an approach for selecting tourism booking services using distributed databases in an IoT environment.

Our algorithm for computing the booking skyline enables the selection of the best tourism services based on the users’ requirements in terms of the cost of travel, location, and travel time. For joining services (tables) in getaways, we determine the location as a join attribute between different tables, leading to the first filtrate in the tables. Tables join is an extension of the original skyline join. The dynamic skyline query is adapted to minimize the search space as much as possible to improve the selection efficiency of the booking services based on the user conditions. The booking skyline is a set of all the services not dynamically dominated by any other service with respect to the distance of a given query service. In particular, we focus on the booking skyline services for user-based service selection, where the ones booked via skyline dominated the no booking skyline services. This is attributed to the fact that the booking skyline services allow better user results than the non booking skyline services.

The steps for executing the proposed skyline procedure are specific in the instructions of Algorithm 1. Table 2 provides the definition of different abbreviations. As noted in the section 4. 1, booking services comprises search and selection processes. It consists of four steps.

Table 2. Different abbreviations used

4.2.1 Capturing the user request

Once a consumer logs in to the users interface, he/she enters his/her requirements through a web interface. Then, the interface manager forwards the request to the server, which sends it to the gateways.

1.png

4.2.2 Computing the LBS

After the gateways receive the user’s request, each local server in the different gateways calculates the LBS. Algorithm 2 illustrates the process of LBS as follows.

2.png

The user’s requirements are divided into three parts: part one for joining relations, part two for determining the scoring attribute between the relations, and part three represents the numerical attributes of every relation. Moreover, the user defines the scoring attribute, which is the main point in the booking skyline algorithms.

After the user’s request arrives, the LBS algorithm group begins the identification of tuples using the join attribute. It is the first filter operation of booking services. Then, we check the service type; if it is not temporary during the travel, we multiply the price attribute of table Bi at a period of travel t.

The second filtering process of reserving data starts from the temporary table LG. For each tuple ti of LG, we calculate the total travel cost and compare it with the scoring attribute of user d; if it agrees with the condition, we apply the skyline query at the numerical attributes. If the tuple agrees with all conditions, we add it in the result of computing LBS.

Step 3—Computing the GBS: after concluding the result of the LBS server, the result is transmitted to the global server, which merges the results of all the booking services and computes the GBS. Algorithm 3 illustrates the process of determining the GBS as follows:

3.png

A GBS algorithm runs right after the results of the local servers are gathered from distributed gateways. This algorithm manages to combine all results into a temporary GBS table. Then, the skyline query is applied to the GBS tuples, where delete dominated tuples by another tuples.

Step 4—Ordering booking services: immediately after calculating the GBS, the final result is integrated within the algorithm of ranking booking results. Then, the result becomes accessible to be displayed to the user.