USER MANUALS

Query Capabilities: Search Methods and Wrappers

Unlike a database, some sources such as SOAP web services or REST APIs do not allow random queries to their data. Instead, they provide an interface with limited query capabilities. For example, an operation of a REST API that has mandatory parameters. Virtual DataPort is capable of modeling the query capabilities of a source using search methods. A base view can have one or more search methods.

Each base view describes its query capabilities through what are known as search methods. If a view does not have at least one search method, it cannot be queried.

We recommend creating base views from the administration tool because it automatically defines the search methods of the view. Almost always, these search methods do not need to be modified.

Each search method of a view is comprised of a series of 5-tuples. Each 5-tuple represents a restriction that a specific query should comply with to be executed on the source using this search method. In this sense, a search method that has no 5-tuple allows every query (this is the case of sources that have no limitations in their query capabilities such as, for example, conventional relational databases).

The format of a 5-tuple is (attribute, operators, obligatoriness, multiplicity, possible_values) where:

  • attribute is an attribute of the relation.

  • operators is the group of operators that can be used in conditions with this attribute in the queries to this view and with this search method. “ANY” represents any operator allowed by the attribute data type.

  • obligatoriness can have three values: “OBL” indicates that the attribute should mandatorily appear in any query to the source. “OPT” indicates that the attribute may or may not appear in the query (it is optional) and “NOS” indicates that the queries for this attribute are not allowed in the source.

  • multiplicity indicates how many values can be included in the source query for the given attribute and operator. If it is not possible to make queries for this attribute (“NOS” value in the obligatoriness field), the value is necessarily 0. “ANY” indicates that a query, for any given attribute and operator, could have any number of values.

  • possible_values is the list of values that can be used to query the attribute. If the value “ANY” is contained in it, this means that the search range is not limited (within the range associated with the attribute data type), and the attribute can be queried about any value. If the obligatoriness field is set in the 5-tuple to the “NOS” value, then it necessarily takes the value of an empty set.

Example: Consider the example of a virtual bookshop on the Internet offering the search form of shown in Search form for a bookshop.

Search form for a bookshop

Search form for a bookshop

The form requires the user to specify a value for the TITLE attribute and gives the option to set a value for the AUTHOR attribute and for the FORMAT attribute (restricted to a group of values). Searches by title and author are searches by keyword (operator like). A search by exact phrase (operator =) is indicated by selecting the box next to the search box of the field. For each attribute, a search can specify one value only. In addition to the fields TITLE, AUTHOR and FORMAT, the shop returns as output a PRICE attribute, which cannot be queried using the form.

Let us model this source as a relation R={TITLE, AUTHOR, FORMAT, PRICE} with a search method containing the 5-tuples shown below.

Search method for a bookshop
(TITLE,{like,=}, OBL, 1, Any)
(AUTHOR, {like,=}, OPT, 1, Any)
(FORMAT, {=}, OPT, 1,
{'All formats', 'Hardcover', 'eBooks', 'Paperbacks'})
(PRICE, {}, NOS, 0, {})

Note that the first 5-tuple has the value {like, =} in the OPERATORS field and OBL in the OBLIGATORINESS field, this does not mean that it is obligatory to query the TITLE attribute with both operators, but that it is obligatory to query it at least with one of them. In order to have the TITLE attribute appear obligatorily in the query with both operators (this is not possible in the form in the example), this should be done with two different 5-tuples for the TITLE attribute, one for each operator:

{(TITLE, {like}, OBL, 1, ANY) (TITLE, {=}, OBL, 1, ANY)}

Thus, as can be seen, when you want to differentiate the treatment of a specific attribute according to the operator with which it is used, more than one 5-tuple can exist for each attribute.

Virtual DataPort automatically calculates the query capabilities of the derived view according to the capabilities of its underlying views.

There is no graphical support to add, modify or delete search methods of a base view.

Add feedback