*3.2.1 Preliminary details*

RPL forms a Destination Oriented Directed Acyclic Graph (DODAG) (**Figure 3**), where each node has a rank calculated according to the cost metric and has a Preferred Parent (PP) as a gateway to the root [7]. In addition, RPL is regulated by three control messages ICMPv6 (Internet Control Message Protocol version 6) as defined in RFC 4443, namely:


As for the objective function, it is indeed a mechanism enabling selection of the parent node by a child node, according to a metric of the DODAG tree. The main RPL specification does not have a built-in objective function, but both the zeroobjective function (OF0) and the minimum order objective function with hysteresis (MRHOF) are recognized as defaulted OFs in this protocol [8, 9].

**Figure 3.** *DODAG Construction.*

*WSN for Event Detection Applications: Deployment, Routing, and Data Mapping Using AI DOI: http://dx.doi.org/10.5772/intechopen.94085*

Proceeding with the actual data traffic handling arrangements, the analysis of the objective functions OF0 and MRHOF should be performed first. Indeed, OF0 is the Objective Function zero, which specifies how nodes select and optimize routes based on the minimum hop count to reach the parent node, while MRHOF stands for Minimum Rank with Hysteresis Objective Function which selects routes minimizing metrics, and uses hysteresis to reduce balancing in response to small changes in the metric.

To note that MRHOF works with Expected Transmission Count metrics (ETX) that are additive along a route and using the minimum rate to select the parent node and calculated according to Eq. (12).

$$ETX = \frac{1}{D\_f \times D\_r} \tag{12}$$

Df denotes "forward delivery ratio" and indicates the likelihood of receiving the packet at the neighboring node.

Dr stands for "reverse delivery ratio" which calculates the probability of receiving the packet ack on receiver node side.

#### *3.2.2 Procedures, tests, and evaluation*

**3.1 Purpose**

Classically, self-powered, low-speed wireless personal area networks, such as 802.15.4, were considered unable to support IP. Now, 6LoWPAN and RPL made this possible. Even with the careful design of RPL routing, there is a need to assess

In this section, focusing on a concrete application, that of event detection, we will assess the impact sending control packets at different time intervals, using different numbers of nodes and different transmission ranges. We will show how the variation of the control packet sending intervals can affect the performance of the routing protocol for low power lossy networks, considering the packet delivery

RPL forms a Destination Oriented Directed Acyclic Graph (DODAG) (**Figure 3**), where each node has a rank calculated according to the cost metric and

has a Preferred Parent (PP) as a gateway to the root [7]. In addition, RPL is regulated by three control messages ICMPv6 (Internet Control Message Protocol

• DODAG Information Object (DIO) which lets a node to discover an RPL

• Destination Advertisement Object (DAO) allowing the propagation of destination information along the DODAG as well as the updating of the

• DODAG Information Solicitation (DIS) for nodes that request to join the

As for the objective function, it is indeed a mechanism enabling selection of the parent node by a child node, according to a metric of the DODAG tree. The main RPL specification does not have a built-in objective function, but both the zeroobjective function (OF0) and the minimum order objective function with hysteresis

topology or to obtain more recent configuration information.

(MRHOF) are recognized as defaulted OFs in this protocol [8, 9].

this protocol in the context of more real-world applications.

*Wireless Sensor Networks - Design, Deployment and Applications*

**3.2 Impact of network environment on the RPL**

version 6) as defined in RFC 4443, namely:

routing table on reception,

rate and the power consumption.

*3.2.1 Preliminary details*

instance,

**Figure 3.**

**108**

*DODAG Construction.*

All simulations are carried out in the CONTIKI OS operating system using the Cooja simulator, considering the settings listed in **Table 1**. To perform the required simulations at various sending intervals (3 seconds, 5 s, 10s, 30s, 60s, 120 s, 300 s), we have modified the default parameter "PERIOD" in the "collect-common.c" file. Seeing that MRHOF is the default objective function for Contiki, we have modified the files rpl-conf.h and rpl-make. We had performed about 70 simulations in Cooja to evaluate the performance of the RPL objective functions in two scenarios.

Scenario 1: we fixed the network densities and modified the values of the TX range.

Scenario 2: we fixed the values of the TX range and modified the network densities.

In both scenarios, we have modified the sending intervals, allowing us to simulate highly constrained applications in lower SI values and normal applications in higher SI values.

In addition, a random topology will be used as this is the most suitable type chosen for the application. We implement a P2M topology, which means that there is only one sink node and the others are emitters, with a simulation time of about 10 minutes (600 seconds). The simulated platform was Tmote Sky under Unit Disk Graph Medium (UDGM) as the radio model. It should be noted that the Tmote Sky platform based on the MSP430 microcontroller with 10 KB of RAM and an


**Table 1.** *Used settings in the cooja simulator.* IEEE802.15.4 compatible radio is a constraint in the simulation of large networks because no more than 40 nodes can be simulated with reference to the hardware specification which leads to the limitation of the memory size of the routing tables [10]. The present work consists in testing the behavior of the two OFs in the RPL routing protocol by varying the SI sending intervals under various TX transmission ranges and different network densities. Following [11] the results of the simulation in the Cooja simulator could give the same results as in a practical experiment despite the external factors. Therefore, we will consider the Cooja results as practical tests. We collect all results obtained during all simulations and express them in graphs. We will discuss these results in subsections dealing only with each scenario.

**Scenario 1:** The network densities were set at 10 nodes and the Tx range values were varied from 50 m (**Figures 4** and **5**) to 100 m (**Figures 6** and **7**). It is clear that the longer the sending intervals, the lower the power consumption is in the case of OF0 and MRHOF, due to the fact that nodes consume more power since they send packets regularly and remain active in shorter intervals. Furthermore, Results indicate that MRHOF is more efficient than OF0 in terms of power consumption for one simple reason: MRHOF uses the ETX metric to build the routing table that reduces the amount of power used to transmit data between nodes.

The same conclusion for PDR, while increasing the sending intervals, the PDR value increases In fact, at tighter time intervals, nodes send packets repeatedly, leading to more load on delivered packets. Therefore, many packets do not reach destination because their capacity becomes exhausted. Thus, extending the send interval will increase the received packets, directly impacting the PDR value. Furthermore, we have noticed that when SI = 30s, MRHOF reaches 100% PDR. This could prove the idea that MRHOF performs better than OF0 in the PDR results because it reaches the full PDR ratio in fewer sending intervals.

**Scenario 2:** This scenario considers the TX range values at 100 m and changes the network densities from 10 nodes (**Figures 6** and **7**) to 15 nodes (**Figures 8** and **9**). Increasing the transmission intervals reduces power consumption. However, power consumption for OF0 and MRHOF are too close in this scenario, but MRHOF is still better.

We also notice that by increasing the network density, the power consumption increases compared to scenario 1, but the difference is not very important because we also increase the transmission range, so that more nodes reach the sink node

without the need to switch from the transmitter to the receiver, thus lowering the

*WSN for Event Detection Applications: Deployment, Routing, and Data Mapping Using AI*

MRHOF reaches a higher PDR level in the former sending intervals, but OF0 is still not very performing and declined in 30 seconds of sending intervals due to

power consumption level.

*Performance in PDR (10 nodes,Tx = 100 m).*

**Figure 5.**

**Figure 6.**

**Figure 7.**

**111**

*Performance in PDR (10 nodes,Tx = 50 m).*

*DOI: http://dx.doi.org/10.5772/intechopen.94085*

*Performance in power consumption (10 nodes,Tx = 100 m).*

**Figure 4.** *Performance in power consumption (10 nodes,Tx = 50 m).*

*WSN for Event Detection Applications: Deployment, Routing, and Data Mapping Using AI DOI: http://dx.doi.org/10.5772/intechopen.94085*

**Figure 5.** *Performance in PDR (10 nodes,Tx = 50 m).*

IEEE802.15.4 compatible radio is a constraint in the simulation of large networks because no more than 40 nodes can be simulated with reference to the hardware specification which leads to the limitation of the memory size of the routing tables [10]. The present work consists in testing the behavior of the two OFs in the RPL routing protocol by varying the SI sending intervals under various TX transmission ranges and different network densities. Following [11] the results of the simulation in the Cooja simulator could give the same results as in a practical experiment despite the external factors. Therefore, we will consider the Cooja results as practical tests. We collect all results obtained during all simulations and express them in graphs. We will discuss these results in subsections dealing only with

*Wireless Sensor Networks - Design, Deployment and Applications*

**Scenario 1:** The network densities were set at 10 nodes and the Tx range values were varied from 50 m (**Figures 4** and **5**) to 100 m (**Figures 6** and **7**). It is clear that the longer the sending intervals, the lower the power consumption is in the case of OF0 and MRHOF, due to the fact that nodes consume more power since they send packets regularly and remain active in shorter intervals. Furthermore, Results indicate that MRHOF is more efficient than OF0 in terms of power consumption for one simple reason: MRHOF uses the ETX metric to build the routing table that

The same conclusion for PDR, while increasing the sending intervals, the PDR value increases In fact, at tighter time intervals, nodes send packets repeatedly, leading to more load on delivered packets. Therefore, many packets do not reach destination because their capacity becomes exhausted. Thus, extending the send interval will increase the received packets, directly impacting the PDR value. Furthermore, we have noticed that when SI = 30s, MRHOF reaches 100% PDR. This could prove the idea that MRHOF performs better than OF0 in the PDR results

**Scenario 2:** This scenario considers the TX range values at 100 m and changes the network densities from 10 nodes (**Figures 6** and **7**) to 15 nodes (**Figures 8** and **9**). Increasing the transmission intervals reduces power consumption. However, power consumption for OF0 and MRHOF are too close in this scenario, but MRHOF

We also notice that by increasing the network density, the power consumption increases compared to scenario 1, but the difference is not very important because we also increase the transmission range, so that more nodes reach the sink node

reduces the amount of power used to transmit data between nodes.

because it reaches the full PDR ratio in fewer sending intervals.

each scenario.

is still better.

**Figure 4.**

**110**

*Performance in power consumption (10 nodes,Tx = 50 m).*

**Figure 6.** *Performance in power consumption (10 nodes,Tx = 100 m).*

**Figure 7.** *Performance in PDR (10 nodes,Tx = 100 m).*

without the need to switch from the transmitter to the receiver, thus lowering the power consumption level.

MRHOF reaches a higher PDR level in the former sending intervals, but OF0 is still not very performing and declined in 30 seconds of sending intervals due to

if one considers WSN as a database. For the purpose of the event detection applications currently in use the processing of requests is a big challenge, so it is necessary

*WSN for Event Detection Applications: Deployment, Routing, and Data Mapping Using AI*

To reduce the cost of executing aggregated queries in event detection applications, events are often pre-calculated and materialized. These aggregated views are commonly known as summary tables that can be used to assist in responding to requests containing information beyond the view it represents. Yet, this provides a significant gain in performance. Many optimization techniques are available in the published work, such as indexing and fragmentation [12–14]. In this section, we

The materialized views technique is mainly used to reduce the workload execution time [15]. It is made of several joints considered expensive to compute and store, especially for large sensor networks. It prepares these joints in the form of materialized views (MV) so that they do not repeat themselves each time. There are several algorithms to create the VMs such as backpack, similarity between queries, cache, etc. We will deal with the Jaccard similarity index approach [16]. The

• The extraction of the workload to create the query attribute table (each query

• For each similarity group we create a cluster (only clusters with high similarity

The Workload *Q* is formed by *n* queries *Q*<sup>1</sup> f g , … *Qn* . A query is composed by *k*

� � <sup>¼</sup> <sup>1</sup> <sup>∗</sup> *<sup>a</sup> <sup>j</sup> if a <sup>j</sup> used in Q* <sup>0</sup> <sup>∗</sup> *<sup>a</sup> <sup>j</sup> else* (

<sup>1</sup> <sup>∗</sup> *f a*ð Þ<sup>1</sup> <sup>⋯</sup> *<sup>a</sup>*<sup>1</sup>

<sup>1</sup> <sup>∗</sup> *f a*ð Þ<sup>1</sup> <sup>⋯</sup> *an*

The database management system has only one Final Solution *FS* (guarantees the re-joining to all workload with minimal cost). *FS* is formed by a set of material-

⋮⋱⋮

*j*

n o, <sup>∀</sup>*<sup>i</sup>* : <sup>1</sup>*::n*, *<sup>j</sup>* : <sup>1</sup>*::k*.

*<sup>k</sup>* ∗ *f a*ð Þ*<sup>k</sup>*

1

CCA

*<sup>k</sup>* ∗ *f a*ð Þ*<sup>k</sup>*

(13)

(14)

to optimize the execution time and the resources used.

*DOI: http://dx.doi.org/10.5772/intechopen.94085*

proposed technique as presented in **Figure 10** consists in:

• Calculation of the similarity between each pair of vectors.

consider materialized views.

is presented by a vector).

• A view will be created for each cluster.

attributes f g *<sup>a</sup>*1, … *ak* , each query is *Qi* <sup>¼</sup> *<sup>a</sup><sup>i</sup>*

The activation function used in this work is:

*f a <sup>j</sup>*

The workload can be presented in form of matrix:

*a*1

0

BB@

*an*

ized views *v*. Each view is composed of one or more attributes. Based on, *N* attributes, we can find 2*<sup>N</sup>* � 1 views and the *FS* has a view between 1 and 2*<sup>N</sup>* � 1.

*MatA* ¼

will be kept).

*4.1.1 Modelization*

**113**

**4.1 Materialized view**

**Figure 8.** *Performance in power consumption (15 nodes,Tx = 100 m).*

**Figure 9.** *Performance in PDR (15 nodes,Tx = 100 m).*

inconsistent network structure, moreover not all nodes in this scenario were able to reach the destination node, what can be considered as unintended findings.

When we take the 60s as the value for the sending intervals, both MRHOF and OF0 had a 100% ratio for the PDR, confirming the fact that the PDR value increases as the sending intervals are incremented.

Finally, selecting an appropriate routing protocol to a given application like event detection is often important and necessary, however, it remains to be said that after the routing of data through the network, it is essential to process them correctly to benefit as much as possible from this content while keeping in mind the limitations of low capacity, low power and lossy networks. The following section outlines in more detail the proposed method for data treatment and mining.

#### **4. Data querying and mining**

Having carefully considered the deployment principles and the proper routing on the network, it remains to specify how to properly handle the data, most notably, *WSN for Event Detection Applications: Deployment, Routing, and Data Mapping Using AI DOI: http://dx.doi.org/10.5772/intechopen.94085*

if one considers WSN as a database. For the purpose of the event detection applications currently in use the processing of requests is a big challenge, so it is necessary to optimize the execution time and the resources used.

To reduce the cost of executing aggregated queries in event detection applications, events are often pre-calculated and materialized. These aggregated views are commonly known as summary tables that can be used to assist in responding to requests containing information beyond the view it represents. Yet, this provides a significant gain in performance. Many optimization techniques are available in the published work, such as indexing and fragmentation [12–14]. In this section, we consider materialized views.

#### **4.1 Materialized view**

The materialized views technique is mainly used to reduce the workload execution time [15]. It is made of several joints considered expensive to compute and store, especially for large sensor networks. It prepares these joints in the form of materialized views (MV) so that they do not repeat themselves each time. There are several algorithms to create the VMs such as backpack, similarity between queries, cache, etc. We will deal with the Jaccard similarity index approach [16]. The proposed technique as presented in **Figure 10** consists in:


#### *4.1.1 Modelization*

inconsistent network structure, moreover not all nodes in this scenario were able to

When we take the 60s as the value for the sending intervals, both MRHOF and OF0 had a 100% ratio for the PDR, confirming the fact that the PDR value increases

Finally, selecting an appropriate routing protocol to a given application like event detection is often important and necessary, however, it remains to be said that after the routing of data through the network, it is essential to process them correctly to benefit as much as possible from this content while keeping in mind the limitations of low capacity, low power and lossy networks. The following section outlines in more detail the proposed method for data treatment and mining.

Having carefully considered the deployment principles and the proper routing on the network, it remains to specify how to properly handle the data, most notably,

reach the destination node, what can be considered as unintended findings.

as the sending intervals are incremented.

*Performance in PDR (15 nodes,Tx = 100 m).*

*Performance in power consumption (15 nodes,Tx = 100 m).*

*Wireless Sensor Networks - Design, Deployment and Applications*

**Figure 8.**

**Figure 9.**

**112**

**4. Data querying and mining**

The Workload *Q* is formed by *n* queries *Q*<sup>1</sup> f g , … *Qn* . A query is composed by *k* attributes f g *<sup>a</sup>*1, … *ak* , each query is *Qi* <sup>¼</sup> *<sup>a</sup><sup>i</sup> j* n o, <sup>∀</sup>*<sup>i</sup>* : <sup>1</sup>*::n*, *<sup>j</sup>* : <sup>1</sup>*::k*.

The activation function used in this work is:

$$f(a\_j) = \begin{cases} 1 \ast a\_j \text{ if } a\_j \text{ used in Q} \\ 0 \ast a\_j \text{ else} \end{cases} \tag{13}$$

The workload can be presented in form of matrix:

$$\mathbf{M} \mathbf{a} \mathbf{t} \mathbf{A} = \begin{pmatrix} a\_1^1 \ast f(a\_1) & \cdots & a\_k^1 \ast f(a\_k) \\ \vdots & \ddots & \vdots \\ a\_1^n \ast f(a\_1) & \cdots & a\_k^n \ast f(a\_k) \end{pmatrix} \tag{14}$$

The database management system has only one Final Solution *FS* (guarantees the re-joining to all workload with minimal cost). *FS* is formed by a set of materialized views *v*. Each view is composed of one or more attributes. Based on, *N* attributes, we can find 2*<sup>N</sup>* � 1 views and the *FS* has a view between 1 and 2*<sup>N</sup>* � 1.

**Figure 10.** *Process of MV making.*

$$FS^f = \left\{ \nu\_e^f \right\}, where e \in \left( \mathbf{1}. \mathbf{2}^N - \mathbf{1} \right), \ f = \left( \mathbf{1}. \mathbf{2}^{2^N - 1} - \mathbf{1} \right) \tag{15}$$

For example, *FS*<sup>1</sup> composed by *v*1, *v*3, *and v*4:

$$F\mathbb{S}^1 = \left\{ v\_1^1, v\_3^1, v\_4^1 \right\} \tag{16}$$

The third level presents all the possible final solutions where *FS* can be formed by one or all the materialized views. Thus, the maximum number of final solutions

*WSN for Event Detection Applications: Deployment, Routing, and Data Mapping Using AI*

Our learning system consists of an input layer serves to receive the *MatA* matrix,

Learning is defined by the process used to find *<sup>W</sup>*^ for all MatA such as *FS* ffi *FS*^ , where FS and *FS*^ represent respectively, the final solution and the desired weight. Thus, the error function *Err MatA* ð Þ , *FS*,*W* (21) measuring the Euclidean distance

The relationship between query-attributes Matrix and Final solutions matrix is

F ¼ G MatA,W ð Þ, *where W is the input weights* (20)

*i*¼1

*MatA* ∗*W* þ *β* ¼ *FS* (22)

ð Þ *MatAi* � *FSi*

<sup>2</sup> (21)

an output layer to receive the *FS* matrix, and hidden layers (**Figure 12**). The f g *MatA*, *FS* present the learning set. For each *MatA* input, the learning network

is 22*<sup>n</sup>*�<sup>1</sup> � 1.

**Figure 11.** *Final solutions tree.*

*4.1.2 Learning practice*

gives a *FS* as a response.

given by Eqs. 22 and 23.

**Figure 12.**

**115**

*Artificial neural network to create MVs.*

The network is presented by the Eq. (20).

*DOI: http://dx.doi.org/10.5772/intechopen.94085*

between the MatA and output *FS* must be minimized.

*Err MatA* ð Þ¼ , *FS*, *<sup>w</sup>* <sup>∥</sup>*MatA* � *FS*∥<sup>2</sup> <sup>¼</sup> <sup>X</sup>*<sup>n</sup>*

In order to verify if this materialized view *ve* is included in the solution *FS <sup>f</sup>* or no, the function *h v*ð Þ*<sup>e</sup>* having the following form should be used

$$h(v\_{\epsilon}) = \begin{cases} \mathbf{1}, & v\_{\epsilon} \text{ if } v\_{\epsilon} \text{ used in FS} \\ \mathbf{0}, & v\_{\epsilon} \text{ else} \end{cases} \tag{17}$$

The maximum number of final solutions is 2*<sup>N</sup>* � <sup>1</sup> � �<sup>2</sup>*N*�<sup>1</sup> . The final solutions are presented as follows

$$FS = \begin{pmatrix} v\_1^1 \ast h(v\_1) & \cdots & v\_{2^N - 1}^{\left(2^N - 1\right)^{2^N - 1}} \ast h(v\_{2^N - 1}) \\ \vdots & \ddots & \vdots \\ v\_1^n \ast h(v\_1) & \cdots & v\_{2^N - 1}^{\left(2^N - 1\right)^{2^N - 1}} \ast h(v\_{2^N - 1}) \end{pmatrix} \tag{18}$$

The references of the final solutions are stored in a vector *VS* (19).

$$\text{VS} = \left\{ \mathbf{S}\_f \right\}, where \, f = \left( \mathbf{1}. \mathbf{2}^{2^N - 1} - \mathbf{1} \right) \tag{19}$$

The sizes based on the final solutions are illustrated in **Figure 11**, where:

The first level illustrates all the attributes f g *a*1, *::*, *an* in the database tables. The second level represents all the possible pointers of the materialized views i.e., *v*1, *::*, *v*2*<sup>n</sup>* f g �<sup>1</sup> .

*WSN for Event Detection Applications: Deployment, Routing, and Data Mapping Using AI DOI: http://dx.doi.org/10.5772/intechopen.94085*

**Figure 11.** *Final solutions tree.*

The third level presents all the possible final solutions where *FS* can be formed by one or all the materialized views. Thus, the maximum number of final solutions is 22*<sup>n</sup>*�<sup>1</sup> � 1.

#### *4.1.2 Learning practice*

*FS <sup>f</sup>* <sup>¼</sup> *<sup>v</sup> <sup>f</sup> e*

**Figure 10.**

*Process of MV making.*

For example, *FS*<sup>1</sup> composed by *v*1, *v*3, *and v*4:

*Wireless Sensor Networks - Design, Deployment and Applications*

� �, *wheree* <sup>∈</sup> <sup>1</sup>*::*2*<sup>N</sup>* � <sup>1</sup> � �, *<sup>f</sup>* <sup>¼</sup> <sup>1</sup>*::*22*<sup>N</sup>*�<sup>1</sup> � <sup>1</sup>

1, *v*<sup>1</sup> 3, *v*<sup>1</sup> 4

1, *ve if ve used in FS*

<sup>2</sup>*<sup>N</sup>* ð Þ �<sup>1</sup> <sup>2</sup>*N*�<sup>1</sup>

<sup>2</sup>*<sup>N</sup>* ð Þ �<sup>1</sup> <sup>2</sup>*N*�<sup>1</sup>

<sup>2</sup>*N*�<sup>1</sup> <sup>∗</sup> *h v*2*N*�<sup>1</sup> ð Þ

<sup>2</sup>*N*�<sup>1</sup> <sup>∗</sup> *h v*2*N*�<sup>1</sup> ð Þ

� �

In order to verify if this materialized view *ve* is included in the solution *FS <sup>f</sup>* or

0, *ve else*

⋮⋱ ⋮

� �, *where f* <sup>¼</sup> <sup>1</sup>*::*2<sup>2</sup>*N*�<sup>1</sup> � <sup>1</sup>

*FS*<sup>1</sup> <sup>¼</sup> *<sup>v</sup>*<sup>1</sup>

no, the function *h v*ð Þ*<sup>e</sup>* having the following form should be used

(

<sup>1</sup> ∗ *h v*ð Þ<sup>1</sup> ⋯ *v*

<sup>1</sup> ∗ *h v*ð Þ<sup>1</sup> ⋯ *v*

The references of the final solutions are stored in a vector *VS* (19).

The sizes based on the final solutions are illustrated in **Figure 11**, where: The first level illustrates all the attributes f g *a*1, *::*, *an* in the database tables. The second level represents all the possible pointers of the materialized views

*h v*ð Þ¼ *<sup>e</sup>*

The maximum number of final solutions is 2*<sup>N</sup>* � <sup>1</sup> � �<sup>2</sup>*N*�<sup>1</sup>

The final solutions are presented as follows

0

BBBB@

*v*1

*vn*

*VS* ¼ *S <sup>f</sup>*

*FS* ¼

i.e., *v*1, *::*, *v*2*<sup>n</sup>* f g �<sup>1</sup> .

**114**

� �

� � (16)

.

1

CCCCA

(15)

(17)

(18)

(19)

Our learning system consists of an input layer serves to receive the *MatA* matrix, an output layer to receive the *FS* matrix, and hidden layers (**Figure 12**). The f g *MatA*, *FS* present the learning set. For each *MatA* input, the learning network gives a *FS* as a response.

The network is presented by the Eq. (20).

$$\mathbf{F} = \mathbf{G}(\mathbf{M}\mathbf{t}\mathbf{A}, \mathbf{W}), where \text{ } \mathbf{W} \text{ is the input weights} \tag{20}$$

Learning is defined by the process used to find *<sup>W</sup>*^ for all MatA such as *FS* ffi *FS*^ , where FS and *FS*^ represent respectively, the final solution and the desired weight. Thus, the error function *Err MatA* ð Þ , *FS*, *W* (21) measuring the Euclidean distance between the MatA and output *FS* must be minimized.

$$Err(MatA, FS, w) = \left\|{MatA - FS}\right\|^2 = \sum\_{i=1}^{n} \left(MatA\_i - F\mathbb{S}\_i\right)^2\tag{21}$$

The relationship between query-attributes Matrix and Final solutions matrix is given by Eqs. 22 and 23.

$$\mathbf{M} \mathbf{a} \mathbf{t} A \ast \mathbf{W} + \boldsymbol{\beta} = F \mathbf{S} \tag{22}$$

**Figure 12.** *Artificial neural network to create MVs.*

Otherwise:

$$\begin{pmatrix} a\_1^1 \ast f(a\_1) & \cdots & a\_k^1 \ast f(a\_k) \\ \vdots & \ddots & \vdots \\ a\_1^n \ast f(a\_1) & \cdots & a\_k^n \ast f(a\_k) \end{pmatrix} \ast \begin{pmatrix} w\_1 \\ \vdots \\ w\_n \end{pmatrix} + \beta$$
 
$$= \begin{pmatrix} v\_1^1 \ast h(v\_1) & \cdots & v\_{2^N - 1}^{\left(2^N - 1\right)^{2^N - 1}} \ast h(v\_{2^N - 1}) \\ \vdots & \ddots & \vdots \\ v\_1^n \ast h(v\_1) & \cdots & v\_{2^N - 1}^{\left(2^N - 1\right)^{2^N - 1}} \ast h(v\_{2^N - 1}) \end{pmatrix} \tag{23}$$

**Algorithm 2:** *Predicting VMs.*

*4 A = Extraction (Qn + 1) 5 Views = A\*W 6 Return Views 7 End*

*3 Begin*

**Figure 14**.

**4.3 Test and result**

results.

**Figure 14.** *Global architecture.*

**117**

*1 Input: Qn + 1: next query, W: weight given by learning algorithm*

The complete process of creating MVs with the learning machine is illustrated in

*WSN for Event Detection Applications: Deployment, Routing, and Data Mapping Using AI*

First, all attributes used in the database tables are identified then every possible solution with the corresponding MV will be generated. Here only references for views are generated, the real MVs can be created in the learning step using Jaccard similarity technique. We identify the MVs per solution within this learning phase so as to find their optimal resolution. The neural network considers the attributes and views obtained when building the model. Once this learning step done, the optimal solution with the attributes present in the Qn + 1 workload will be found by the model.

Concrete case examples will be considered to make the tests and deduce the

*2 Output: Final solution (Materialized Views set)*

*DOI: http://dx.doi.org/10.5772/intechopen.94085*

Note: *β* is the bias.

#### **4.2 Algorithms**

The proposed approach is structured in two algorithms, the one for generating VMs and the other for their prediction.

**Algorithm 1:** *Building VMs*

```
1 Input: Q: Workload, LP: learning period, Aused: Attributes used in Q, A: Attributes set
2 Output: FS: Final solution
*/ Final solution = materialized Views set */
3 Setup:
4 A: array () array of pointers of all attributes defined in the database
5 V: array () of pointers of all possible materialized views
6 FS: array () of pointers of all possible final solutions
7 Start
8 While (counter < LP) {
9 Aused extraction(Q)
10 MatQA query_attributes(Aused,Q)
11 MatJS Jaccard_similarity (MatQA)
12 Graphs graph (MatJS)
13 Views cluster (Graphs)
14 Training_views (MatA, FS)
15 Counter ++
16 }
17 FS prediction_views(Q)
18 End
```
Prior to the start, the training period must be tested (**Figure 13**). Once it is running, the algorithm follows the usual processes by creating the attributes of the query matrix and finding similarities between each vector.

**Figure 13.** *Switching between the training phase and the prediction phase.*

*WSN for Event Detection Applications: Deployment, Routing, and Data Mapping Using AI DOI: http://dx.doi.org/10.5772/intechopen.94085*

#### **Algorithm 2:** *Predicting VMs.*

Otherwise:

Note: *β* is the bias.

**Algorithm 1:** *Building VMs*

*2 Output: FS: Final solution*

*8 While (counter < LP) { 9 Aused extraction(Q)*

*12 Graphs graph (MatJS) 13 Views cluster (Graphs) 14 Training\_views (MatA, FS)*

*17 FS prediction\_views(Q)*

**4.2 Algorithms**

*3 Setup:*

*7 Start*

*15 Counter ++ 16 }*

*18 End*

**Figure 13.**

**116**

*a*1

0

BBB@

*an*

0

BBBBB@

¼

VMs and the other for their prediction.

*\*/ Final solution = materialized Views set \*/*

*10 MatQA query\_attributes(Aused,Q) 11 MatJS Jaccard\_similarity (MatQA)*

<sup>1</sup> <sup>∗</sup> *f a*ð Þ<sup>1</sup> <sup>⋯</sup> *<sup>a</sup>*<sup>1</sup>

*Wireless Sensor Networks - Design, Deployment and Applications*

<sup>1</sup> <sup>∗</sup> *f a*ð Þ<sup>1</sup> <sup>⋯</sup> *an*

*v*1

*vn*

⋮⋱⋮

<sup>1</sup> ∗ *h v*ð Þ<sup>1</sup> ⋯ *v*

<sup>1</sup> ∗ *h v*ð Þ<sup>1</sup> ⋯ *v*

*1 Input: Q: Workload, LP: learning period, Aused*: *Attributes used in Q, A: Attributes set*

*4 A: array () array of pointers of all attributes defined in the database*

query matrix and finding similarities between each vector.

*Switching between the training phase and the prediction phase.*

*5 V: array () of pointers of all possible materialized views 6 FS: array () of pointers of all possible final solutions*

*<sup>k</sup>* ∗ *f a*ð Þ*<sup>k</sup>*

1

*w*1

1

CCCA þ *β*

1

CCCCCA

(23)

0

BBB@

<sup>2</sup>*N*�<sup>1</sup> <sup>∗</sup> *h v*2*N*�<sup>1</sup> ð Þ

<sup>2</sup>*N*�<sup>1</sup> <sup>∗</sup> *h v*2*N*�<sup>1</sup> ð Þ

⋮

*wn*

CCCA ∗

<sup>2</sup>*<sup>N</sup>* ð Þ �<sup>1</sup> <sup>2</sup>*N*�<sup>1</sup>

<sup>2</sup>*<sup>N</sup>* ð Þ �<sup>1</sup> <sup>2</sup>*N*�<sup>1</sup>

*<sup>k</sup>* ∗ *f a*ð Þ*<sup>k</sup>*

⋮⋱ ⋮

The proposed approach is structured in two algorithms, the one for generating

Prior to the start, the training period must be tested (**Figure 13**). Once it is running, the algorithm follows the usual processes by creating the attributes of the


The complete process of creating MVs with the learning machine is illustrated in **Figure 14**.

First, all attributes used in the database tables are identified then every possible solution with the corresponding MV will be generated. Here only references for views are generated, the real MVs can be created in the learning step using Jaccard similarity technique. We identify the MVs per solution within this learning phase so as to find their optimal resolution. The neural network considers the attributes and views obtained when building the model. Once this learning step done, the optimal solution with the attributes present in the Qn + 1 workload will be found by the model.

#### **4.3 Test and result**

Concrete case examples will be considered to make the tests and deduce the results.

**Figure 14.** *Global architecture.*
