A condition is satisfied when the value of the corresponding attribute satisfies the test established in the condition. When an object or link has more than one value for a particular attribute, a condition on that entity is satisfied if any member of the set of attribute values for that entity satisfies the condition.^[2]

Consider a movie database that links actors to the movies they appear in. Each of these links includes a Role attribute that lists the characters the actor played in the movie. In Monty Python and the Holy Grail, Graham Chapman played several roles, so the edge connecting Graham Chapman to Monty Python and the Holy Grail has a Role attribute with multiple values: King Arthur, Voice of God, Middle Head and Hiccuping Guard. A relevant fragment of such a database is shown in Figure 3.8.

To find actors and the movies in which they played King Arthur we create a query that requires an edge condition Role = King Arthur, as shown in Figure 3.9.

The pair of Peter Cook and Jake’s Journey is returned as a match because the link connecting them has a Role attribute with a single value of King Arthur. The link connecting Graham Chapman to Monty Python and the Holy Grail has multiple values for the Role attribute. Because King Arthur is one of these values, this link also matches the condition on the query edge. The results of the query are shown in Figure 3.10.

As we have seen before, even though the condition only requires matching a single attribute value, the matching subgraph includes all values for the Role attribute.

Because QGraph considers the condition to be satisfied if any attribute value for the corresponding database entity satisfies the condition, care must be taken in defining queries and interpreting results when objects or links have multiple values for that attribute. For example, books are often released in different formats over time: hard cover, trade paperback, mass market paperback, etc. As a result, a single book can have multiple publication dates, as shown in Figure 3.11.

Consider a condition that tests the publication date for a book, e.g.,

Because 1981 is a member of the set of values for Carrie’s PubDate attribute, the condition is satisfied and Carrie matches a query vertex with this condition.

But because Carrie’s PubDate attribute contains other values, the condition

is also satisfied. The other values for this attribute (1974, 1993, and 2003) make the expression true. Similarly, the conditions

are also satisfied because at least one PubDate value satisfies each of these tests.

Because objects and links in a Proximity database can be structurally heterogeneous, some entities may not have a value for the attribute listed in a condition. In such cases, an attribute condition’s test always fails because there are no values to compare against the condition’s requirements. Consider the database fragment shown in Figure 3.12.

Two of the movies, Carrie and It, have a ReleaseType attribute that indicates whether the movie was released in theaters or made for TV. The third movie, Pet Sematary, does not have a value for this attribute. If we execute the query shown below

we get the results shown in Figure 3.14.

The query finds only a single matching movie, Carrie, which was released theatrically. Both It, which was made into a TV movie, and Pet Sematary, which does not include a release type, do not match the query’s condition.

Objects and links that do not have the specified attribute similarly fail to match inequality conditions. The query shown in Figure 3.15, below, also finds books made into theatrical movies. For the given database fragment, where the ReleaseType attribute can only take a single value drawn from the choices theater or TV, this query is equivalent to the query shown earlier in Figure 3.13.

This new query yields the same results as the original. In addition to excluding the movie It because its value for the ReleaseType attribute is TV, it also excludes the movie Pet Sematary because this object has no value for the ReleaseType attribute. It’s important to note that the equivalence of these two queries depends on the database enforcing the restriction of legal values for the ReleaseType attribute to those specified. If, for example, the database also lets ReleaseType assume values of video and DVD, this equivalence no longer holds.