US 20090177697 A1
A method is provided for generating a materialized view recommendation for at least one back-end server that is connected to a front-end server in a heterogeneous, distributed database system that comprises parsing a workload of federated queries to generate a plurality of query fragments; invoking a materialized view advisor on each back-end server with the plurality of query fragments to generate a set of candidate materialized views for each of the plurality of query fragments; identifying a first set of subsets corresponding to all nonempty subsets of the set of candidate materialized views for each of the plurality of query fragments; identifying a second set of subsets corresponding to all subsets of the first set of subsets that are sorted according to a dominance relationship based upon a resource time for the at least one back-end server to provide results to the front-end server for each of the first set of subsets; and performing a cost-benefit analysis of each of the second set of subsets to determine a recommended subset of materialized views that minimizes a total resource time for running the workload against the at least one back-end server.
1. A method for generating a materialized view recommendation for at least one back-end server that is connected to a front-end server in a heterogeneous, distributed database system, the method comprising:
parsing a workload of federated queries received by the front-end server to generate a plurality of query fragments corresponding to the workload;
invoking a materialized view advisor on each of the at least one back-end server with the plurality of query fragments to generate a set of candidate materialized views for each of the plurality of query fragments;
identifying a first set of subsets corresponding to all nonempty subsets of the set of candidate materialized views for each of the plurality of query fragments;
identifying a second set of subsets corresponding to all subsets of the first set of subsets that are sorted according to a dominance relationship that is based upon a resource time for the at least one back-end server to provide results to the front-end server for each of the first set of subsets; and
performing a cost-benefit analysis of each of the second set of subsets to determine a recommended subset of materialized views that minimizes a total resource time for running the workload against the at least one back-end server.
2. The method of
3. The method of
creating a ranked list of subsets of the second set of subsets that is sorted according to a calculated value of the resource time for the at least one back-end server to provide results to the front-end server divided by an overhead cost for each subset in descending order;
removing each subset from ranked list of subsets that cannot fit in the at least one back-end server;
removing a head subset from the ranked list of subsets is removed and adding the materialized views of the head subset to a recommendation list; and
recalculating the calculated value for each subset remaining in the ranked list of subsets by considering the possible impact of the materialized views in the recommendation list.
4. The method of
5. The method of
1. Field of the Invention
Exemplary embodiments of the present invention relate database querying, and more particularly to MQT recommendations for distributed databases.
2. Description of Background
A federated database system is a type of meta-database management system (DBMS) that transparently integrates multiple autonomous database systems into a single federated database. Thus, a federated database is the fully integrated, logical composite of all constituent databases in a federated database system. Because the constituent database systems remain autonomous, a federated database system presents a workable alternative to the possibly overwhelming task of merging together several disparate databases.
A wide variety of applications require access to multiple heterogeneous, distributed data sources. Data can be distributed among multiple databases that could be stored in a single computer or multiple computers, which may be geographically decentralized but interconnected by a network. Heterogeneities in databases can arise due to several factors, including differences in structures, semantics of data, the constraints supported, or query language. Through data abstraction, federated database systems can provide a uniform front-end user interface that enables users and clients to store and retrieve data in multiple noncontiguous databases with a single query, even if the constituent databases are heterogeneous. To this end, a federated database system first operates to deconstruct the query into subqueries for submission to the relevant constituent DBMSs, then integrates the resulting sets of the subqueries. Because various database management systems employ different query languages, federated database systems can apply wrappers to the subqueries to translate them into the appropriate query languages. By transparently integrating such diverse data sources, underlying differences in DBMSs, languages, and data models can be hidden, and users can employ a single data model and a single high-level query language for accessing the unified data through a global schema.
For example, many large insurance companies require access to distributed and often heterogeneous databases for business intelligence (BI) applications used to gather, provide access to, and analyze data and information about company operations. Typically, distributed databases are integrated into a centralized data warehouse for the benefit of easy maintenance. By integrating distributed databases, these companies can enhance the insurance underwriting process; enable a single view of the customer; provide greater intelligence and data about individual customer needs for up-selling and cross-selling purposes; improve the ability to capture, track and display performance information for management; and improve the database-intensive clearance process during which databases from multiple branches must be searched. This approach, however, needs to overcome the complexity of data loading and job scheduling, as well as scalability issues.
To support federation of such distributed databases, IBM has developed the WebSphere Information Integrator (WebSphere II), which provides relational access to both relational DBMSs and non-relational sources such as file systems and Web services. The remote data sources are registered within WebSphere II as nicknames and thereafter can be accessed via wrappers. Statistics about the remote data sources are collected and maintained in WebSphere II for later use by the query optimizer for estimating the cost of query plans. From the view of a federation, WebSphere II is a federation server and the remote data sources/databases are remote servers. From the view of a multi-tiered enterprise information system, WebSphere II is a front-end server while the remote data sources/databases are back-end servers, which are accessed by users indirectly through the front-end server. An exemplary architecture of such a distributed data warehouse 10 is provided in
BI applications typically require great computation power for performing data intensive processes that aggregate large amounts of data. Therefore, the approach of a fully federated system may not be feasible for data intensive BI applications. To significantly improve the performance of database querying in such applications, a materialized view or Materialized Query Table (MQT), which is an auxiliary table with pre-computed data representing the query result that is cached and may be updated from the original base tables from time to time, can be used. An MQT Advisor (MQTA) is often used to recommend and create MQTs to reduce the query processing cost by replacing parts of queries with existing and appropriately matched MQTs. State-of-the-art MQT advisors that are employed in commercial DBMSs such as the IBM DB2 Design Advisor can be used to recommend MQTs for a stand-alone database.
An exemplary architecture of a stand-alone database 20 is provided in
To overcome the first limitation described above, a hybrid approach using a Data Placement Advisor (DPA) has been proposed for recommending MQTs for distributed databases. For access of multiple back-end database systems in BI applications, a DPA can be implemented to recommend and place MQTs on the federation server to improve the performance of complex, federated queries. The hybrid approach employing intelligent data placement is more flexible and applicable than centralized or full-federation configurations. The current implementation of this hybrid approach to integrating distributed databases is to aggregate selected data from various remote sources as materialized views and cache the aggregated data at the federation server to improve the performance of complex BI query workloads.
Nevertheless, the caching of MQTs at the front-end server in the current implementation of this hybrid approach will not usually be able to help all the queries in a workload. This is because typically only a subset of the queries utilizes MQTs. Moreover, only a subset of the MQT candidates are recommended by DPA due to the disk space constraint imposed. In any case, there are some queries that must access data at the back-end servers. Furthermore, the data aggregation is performed at the front-end server for creating and refreshing of the MQTs. Because creating and refreshing MQTs are expensive tasks, this approach is suitable only when the federation server is substantially more powerful than the back-end servers and the front-end server is not used as a production system when the data aggregation is performed. Finally, in performing data refreshment, because the MQTs and the base tables used to derive the MQTs are in different servers, MQTs can only be refreshed periodically instead of being refreshed in real time. As a result, this approach not suitable for BI applications in which freshness of MQTs is critical.
The shortcomings of the prior art can be overcome and additional advantages can be provided through exemplary embodiments of the present invention that are related to a method for generating a materialized view recommendation for at least one back-end server that is connected to a front-end server in a heterogeneous, distributed database system. The method comprises parsing a workload of federated queries to generate a plurality of query fragments; invoking a materialized view advisor on each back-end server with the plurality of query fragments to generate a set of candidate materialized views for each of the plurality of query fragments; identifying a first set of subsets corresponding to all nonempty subsets of the set of candidate materialized views for each of the plurality of query fragments; identifying a second set of subsets corresponding to all subsets of the first set of subsets that are sorted according to a dominance relationship based upon a resource time for the at least one back-end server to provide results to the front-end server for each of the first set of subsets; and performing a cost-benefit analysis of each of the second set of subsets to determine a recommended subset of materialized views that minimizes a total resource time for running the workload against the at least one back-end server.
Additional features and advantages are realized through the techniques of the present invention. Other embodiments and aspects of the invention are described in detail herein and are considered a part of the claimed invention. For a better understanding of the invention with advantages and features, refer to the description and to the drawings.
As a result of the summarized invention, technically we have achieved a solution that can be implemented to provide MQT recommendation for multiple back-end servers that are connected to a production front-end server that may or may not allow MQTs by taking into consideration the correlation between MQTs as well the parallelism property of multiple back-end distributed systems. Exemplary embodiments of the present invention can be implemented to coordinate the MQT recommendation process for multiple back-end servers and enable the recommendation process to scale well with the number of back-end servers. Exemplary embodiments can be significantly more efficient and effective in providing MQT recommendation than the existing art.
The subject matter that is regarded as the invention is particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The foregoing and other objects, features, and advantages of the invention are apparent from the following detailed description of exemplary embodiments of the present invention taken in conjunction with the accompanying drawings in which:
The detailed description explains exemplary embodiments of the present invention, together with advantages and features, by way of example with reference to the drawings. The flow diagrams depicted herein are just examples. There may be many variations to these diagrams or the steps (or operations) described therein without departing from the spirit of the invention. For instance, the steps may be performed in a differing order, or steps may be added, deleted or modified. All of these variations are considered a part of the claimed invention.
While the specification concludes with claims defining the features of the invention that are regarded as novel, it is believed that the invention will be better understood from a consideration of the description of exemplary embodiments in conjunction with the drawings. It is of course to be understood that the embodiments described herein are merely exemplary of the invention, which can be embodied in various forms. Therefore, specific structural and functional details disclosed in relation to the exemplary embodiments described herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the present invention in virtually any appropriate form. Further, the terms and phrases used herein are not intended to be limiting but rather to provide an understandable description of the invention.
Exemplary embodiments of the present invention are directed to an implementation within a distributed database system that recommends Materialized Query Tables (MQTs) for back-end servers to improve subqueries by considering correlation between back-end servers. Exemplary embodiments can be implemented to recommend MQTs that are well coordinated among back-end servers and optimized for workload to provide the benefits of load distribution and easy maintenance of aggregated data in conjunction with the current hybrid approach of data placement. Exemplary embodiments can be implemented to exploit the parallelism property provided by simultaneous processing among the back-end servers so as to run nearly linearly with respect to the number of back-end servers without sacrificing its recommendation quality. Exemplary embodiments can be implemented in combination with the approach of data placement by aggregating selected data from various remote sources as materialized views and caching the aggregated data at the front-end federation server to improve the performance of complex query workloads.
Referring now to
FMQTA 38 can be implemented to further improve the performance of the federated queries. As an example, assume front-end MQTs can improve the performance of the federated workload by 50 percent, and FMQTA 38 can recommend back-end MQTs that can further improve the performance of the workload by 50 percent. The resulting total improvement would then be 75 percent. Furthermore, in an alternative example, the caching of MQTs at the back-end servers can improve the performance of the federated queries even when front-end MQTs are not present. Nevertheless, recommending MQTs at multiple back-end servers also raises some unique technical challenges that do not appear in recommending front-end MQTs. First, the placing of MQTs on multiple back-end databases calls for intelligent coordination between these back-end servers. Second, scalability becomes more a more prominent issue, and thus, a properly designed algorithm is needed to avoid implementing an exponential approach that may fail even for a small number of back-end servers.
In exemplary embodiments, an FMQTA can be implemented to execute an algorithm that recommends MQTs for all the back-end servers in a coordinated way by using the correlation information about the MQTs (for example, whether MQTs are used by the same federated query) so as to maximize the synergy among the recommended MQTs on different back-end servers. To illustrate the use of such an algorithm,
In exemplary embodiments, to avoid the exponential solution, the parallelism property provided by simultaneous processing in multi-back-end systems can be exploited to reduce the complexity of the algorithm. Such an approach can be implemented to not only be effective in MQT recommendation but also scalable and efficient to run.
An exemplary distributed system topology 40 within which exemplary embodiments of the present invention can be implemented and a general operational flow of executing an exemplary federated query within such a system is illustrated in
Users can query back-end servers 44 through front-end server 42. An example of a user query might be a federated query that requires access to data from multiple back-end servers. As illustrated in exemplary system topology 40, there are three general steps involved when front-end 44 server executes a federated query. First, front-end server 44 parses the federated query into query fragments (or subqueries) such that each query fragment only accesses tables in one back-end server. Next, each query fragment is sent to its corresponding back-end server, and the partial results for each are returned to front-end server 44. Front-end server 44 then integrates the partial results to generate the final answer to the federated query. It follows that the total resource time for running a federated query can generally be divided into three components corresponding to these three processing steps, respectively. While the times corresponding to the first and third steps are invariant for a given federated query, the time for the second step could be different as different MQTs are placed on back-end servers 44, even for the same federated query.
For ease of reference, a function t can be provided by the following definition: Given a federated query q, the function t(q) denotes the resource time required by the front-end server to complete the return of the partial result for each query fragment sent from all of the back-end servers in the second step. Letting q[i] correspond to the query fragment that is sent to back-end server i, t(q[i]) then stands for the resource time required by the front-end server to complete the second step for back-end server i. It follows that t(q) is the maximum of t(q[i]). In exemplary embodiments, the function t can be provided using a cost estimator and its result can depend on the MQT placement on back-end servers. In exemplary embodiments, the function t can additionally accept a set of MQTs as a second parameter. For example, letting v correspond to a set of MQTs, t(q; v) then corresponds to the resource time for federated query q when the MQTs in set v are placed at corresponding back-end servers.
In exemplary embodiments, a federated MQTA can be employed that takes into consideration the correlation among multiple back-end servers in a distributed system when it recommends MQTs for these multiple back-end servers. The federated MQTA can implement an algorithm that, given a workload with K federated queries and a space limit for each back-end server for storing MQTs, recommends MQTs for each back-end server such that the total resource time for running the workload is minimized. The times for parsing queries and integrating partial results at the front-end server are independent of the MQT placement at back-end servers. Thus, the goal of the algorithm can be stated as minimizing the total of t(qi), for 1<=i<=K.
In exemplary embodiments, the FMQTA can consider the usage correlation among the back-end servers so as to recommend MQTs for the back-end servers that provide the maximum overall benefits for the federated queries. In exemplary embodiments, the FMQTA can implement a local search algorithm, such as a greedy hill climbing algorithm, that can be utilized to pick the best candidate MQTs for recommendation at each iterative step until no space is available at the back-end servers. During each iterative step, an MQT or a group of MQTs is selected that can provide the most return (that is, the greatest reduction in query time) on investment (that is, the required disk space to store these MQTs) to the federated workload.
In the present exemplary embodiment, to avoid overlooking the correlation between back-end servers, the FMQTA can also be implemented to consider groups of MQTs that come from multiple back-end servers but are used by the same federated query. In general principle, the algorithm considers any subset of the set of MQTs from all the back-end servers and used by the federated queries, and such a subset is referred to as an MQT group. As an example, for the query shown
Turning now to
In exemplary embodiments, the what-if process performed at block 150 can involve two primary concepts: (1) a virtual caching unit (VCU), which is either a singleton candidate MQT or a set of candidate correlated MQTs that are used together by a federated query; and (2) return on investment (ROI) for each VCU. The ROI for a VCU is the net benefit of the VCU (that is, additional benefit minus additional overhead) for the workload when the MQTs in the VCU are placed on top of the already-placed MQTs. The investment is the total size of the MQTs in the VCU and their indexes, excluding the already-placed MQTs. The ROI of the VCU is the calculated net benefit divided by the calculated size.
A VCU is the primitive unit of consideration during the what-if analysis. The VCUs from each federated query are put together as the list of candidate VCUs for the what-if analysis. The resulting candidate VCUs are much fewer than those that would be generated by a native approach that inspects the benefits all the subsets of the set of candidate MQTs, in which the total number of candidate subsets is exponential to the number of candidate MQTs. The ROI provides a priority value for each VCU. A VCU with the highest ROI value is chosen over those with lower ROI values. The benefit of a VCU is measured as the resource time gain with respect to the front-end server of the federated query if that VCU is recommended.
As an example,
In exemplary embodiments, the what-if analysis performed by an FMQTA can involve a five-step process, as illustrated in the flow diagram provided in
In the present exemplary embodiment, the algorithmic complexity of process 300 and the number of calls to the cost estimator (through the function t) are both polynomial to the number of candidate VCUs and the number of federated queries. More particularly, the algorithmic complexity can be expressed as O(|W|*|V|2), where |W| represents the number of queries in the workload and |V| represents the number of candidate VCUs considered. All VCUs could be selected one after another through what-if process 300 illustrated in
In exemplary embodiments in which the number of back-end servers is large and each federated query requires data from many back-end servers, the number of candidate VCUs from each federated query in the what-if process can be reduced so that the number of candidate VCUs can avoid being exponential to the number of MQTs used by the query. Rather, the number of candidate VCUs can be made linear to the number of MQTs used by the query so as to avoid evaluation of all possible combinations. To provide this scalability without losing any good solution in the search space, an FMQTA can be implemented that exploits the parallelism property of multi-back-end distributed systems to provide for a lossless solution. According to the parallelism property, subqueries with longer execution time can decide the final completion time of all the subqueries—that is, slower subqueries can dominate faster subqueries, and thus, the time to collect partial results from multiple back-end servers is dominated by the most costly back-end server. This ability to dominate can allow for the MQTs for the dominant subqueries to be favored over the MQTs for the dominated subqueries, and concurrently enable reduction of the number of candidate MQTs to be investigated during each step by not considering the subqueries for candidate MQTs that are dominated by the dominant subqueries.
The parallelism property can be defined as follows: Letting q be a federated query against N back-end servers, under function t, t(q), t(q), . . . , t(q[N]) are the times needed for the front-end server to collect the partial results from the respective back-end servers. Then, the total time required by the front-end server to collect all the partial results (that is, t(q)) is equal to max(t(q), t(q), . . . , t(q[N])). The intuition behind this definition is that, because the back-end servers run their corresponding query fragments in parallel, the front-end server only needs to wait as much time as required to collect the partial result from the slowest back-end server.
In exemplary embodiments, the parallelism property can be applied with restriction to find candidate VCUs. For instance, under a one-MQT assumption, given a federated query q, it is assumed that each query fragment q uses at most one candidate MQT on back-end server i. In the following discussion of exemplary embodiments in which this restriction is applied, it is assumed that each federated query in consideration must access all the back-end servers in the system (that is, there is one query fragment for each back-end server). Of course, it should be noted that this assumption is non-limiting, and that such a restriction can also be applied to cases in which a federated query only accesses a subset of the back-end servers. In the example described above with reference to
Therefore, by applying the parallelism property, the FMQTA becomes aware that, if a dominated MQT appears in some VCU v, the VCU must also contain the dominating MQT for it to have positive ROI value. It follows that a VCU that does not contain the dominating MQT does not have positive ROI value. This observation can be used in exemplary embodiments to implement the following algorithm for finding nontrivial VCUs using the parallelism property. First, the MQTs used by a federated query are sorted according to their dominance relationship (each MQT in the sorted list is dominated by all the preceding MQTs in the list). Then, for each MQT, MQTi in the list, one candidate VCU is created that contains MQTi and its dominating MQTs (that is, all the MQTs preceding MQTi). The sorted list can be referred to as a dominance path. For instance, in the example described above with reference to
The algorithmic complexity of the what-if analysis using the parallelism property as described above remains the same as before: O(|W|*|V|2). The number of VCUs |V|, however, is greatly reduced. More particularly, applying the parallelism property, the number of candidate VCUs for each federated query, as well as the number of calls to the cost estimator, is linear to the number of MQTs accessed by the federated query.
In practical exemplary embodiments, multiple MQTs can be used by each query fragment. As an example,
A dominance relationship does not exist for MQTs on the same back-end server. Rather, MQTs used by the same query fragment can add up together to dominate MQTs on other back-end servers, although each individual MQT might not do so. For example, the fifth t value in
To ensure that all candidate VCUs are maintained, an FMQTA can be implemented in exemplary embodiments to consider all of the nonempty subsets of MQTs used by each query fragment by relaxing the one-MQT assumption. In
It should be noted that the foregoing examples are non-limiting, and that the principles described can be generalized for any number of multiple federated queries in exemplary embodiments.
In exemplary embodiments, materialized views can be maintained in data warehouses. In exemplary embodiments, these data warehouses can be implemented to perform incremental view maintenance and perform local refreshment of the MQTs recommended by FMQTAs on back-end servers. Exemplary embodiments can be implemented to analyze an entire workload and proactively cache MQTs for matching incoming queries rather than being triggered by incoming queries. In exemplary embodiments, a middleware software component such as, for example, DBPRoxy and TimesTen, can be incorporated to provide caching functionality for query results in the main memory at the front-end database. The query results can be cached and assigned with TTL (Time to Live) for exploration. Incoming queries can be compared with cached query results via containment checks in which if the incoming queries are contained by the cached query results, the queries are answered by the cached results. In exemplary embodiments, the cache replacement management can be based upon a LFU (Least Frequently Used) strategy, in which a count of how often item are needed is kept, and those that are used least often are discarded first.
Exemplary embodiments of the present invention can be implemented to match incoming queries by analyzing the entire workload and proactively cache MQTs. Exemplary embodiments can be implemented to support a data placement advisor to recommend what MQTs to place in the caches in the federation server or remote server. The FMQTA can be implemented to focus on the queries submitted to the remote servers regardless of whether there is a cache hit at the federation server. Exemplary embodiments can be implemented within a system in which the remote servers are heterogeneous database systems and could have their own MQT advisors. Exemplary embodiments can be implemented within a system in which the federation server may or may not be parallelism aware.
Exemplary embodiments can be implemented any suitable heterogeneous, distributed database management system such as, for example, a federated database system, as well as within database systems that are configured to perform parallel database processing and those configured to perform only serial database processing. Exemplary embodiments can be implemented as a middleware software component that can be deployed outside of the database systems and utilize MQT selection across multiple remote servers to achieve parallelism. Exemplary embodiments can be implemented to handle both federated query workload and local query workload on the remote servers in the federated query workload because these local queries will be routed to their original remote servers. Exemplary embodiments can be applied to shared-nothing parallel database systems in which data is horizontally partitioned among multiple independent nodes, as well to situations in which each node has different load, computation power, and/or disk space constraints. Exemplary embodiments can be implemented, for a given partition, to adjust load distribution via MQT selection to ensure better load balance and parallelism across multiple nodes for shared-nothing parallel database systems.
The capabilities of exemplary embodiments of present invention described above can be implemented in software, firmware, hardware, or some combination thereof, and may be realized in a centralized fashion in one computer system, or in a distributed fashion where different elements are spread across several interconnected computer systems. Any kind of computer system—or other apparatus adapted for carrying out the methods and/or functions described herein—is suitable. A typical combination of hardware and software could be a general purpose computer system with a computer program that, when being loaded and executed, controls the computer system such that it carries out the methods described herein. Exemplary embodiments of the present invention can also be embedded in a computer program product, which comprises features enabling the implementation of the methods described herein, and which—when loaded in a computer system—is able to carry out these methods.
Computer program means or computer program in the present context include any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after conversion to another language, code or notation, and/or reproduction in a different material form.
Therefore, one or more aspects of exemplary embodiments of the present invention can be included in an article of manufacture (for example, one or more computer program products) having, for instance, computer usable media. The media has embodied therein, for instance, computer readable program code means for providing and facilitating the capabilities of the present invention. The article of manufacture can be included as a part of a computer system or sold separately. Furthermore, at least one program storage device readable by a machine, tangibly embodying at least one program of instructions executable by the machine to perform the capabilities of the exemplary embodiments of the present invention described above can be provided.
For instance, exemplary embodiments of the present invention can be implemented within the exemplary embodiment of a hardware configuration provided for a computer system in
The above-described program or modules implementing exemplary embodiments of the present invention can work on processor 512 and the like to perform shape interpolation. The program or modules implementing exemplary embodiments may be stored in an external storage medium. In addition to system disk 527, an optical recording medium such as a DVD and a PD, a magneto-optical recording medium such as a MD, a tape medium, a semiconductor memory such as an IC card, and the like may be used as the storage medium. Moreover, the program may be provided to computer system 510 through the network by using, as the recording medium, a storage device such as a hard disk or a RAM, which is provided in a server system connected to a dedicated communication network or the Internet.
Although exemplary embodiments of the present invention have been described in detail, it should be understood that various changes, substitutions and alternations can be made therein without departing from spirit and scope of the inventions as defined by the appended claims. Variations described for exemplary embodiments of the present invention can be realized in any combination desirable for each particular application. Thus particular limitations, and/or embodiment enhancements described herein, which may have particular advantages to a particular application, need not be used for all applications. Also, not all limitations need be implemented in methods, systems, and/or apparatuses including one or more concepts described with relation to exemplary embodiments of the present invention.
The flow diagrams depicted herein are just examples. There may be many variations to these diagrams or the steps (or operations) described therein without departing from the spirit of the invention. For instance, the steps may be performed in a differing order, or steps may be added, deleted or modified. All of these variations are considered a part of the claimed invention.
While exemplary embodiments of the present invention have been described, it will be understood that those skilled in the art, both now and in the future, may make various modifications without departing from the spirit and the scope of the present invention as set forth in the following claims. These following claims should be construed to maintain the proper protection for the present invention.