Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> comp.databases.theory -> Re: Constraints and Functional Dependencies

Re: Constraints and Functional Dependencies

From: Sampo Syreeni <>
Date: Wed, 28 Feb 2007 23:43:26 +0200
Message-ID: <>

On 2007-02-28, paul c wrote:

> 2) When inserting a TIF image of one person or a JPG of the same
> person, is there a way an engine could consider the TIF and JPG equal?

AFAICT, the problem is that the so called "equivalence predicate" between two pictures, as seen by the database end user, has nothing to do with binary equivalence, nor is it even a higher level equivalence relation in the formal, mathematical sense. Rather it is a more or less reflexive, more or less symmetric, and definitely not transitive relation between images.

That means the end user never wants to use an equality predicate in a query, because even a query aiming at a single answer (conventionally "select x from y where y.attribute=known_value") would most likely search on a probabilistic/fuzzy predicate (i.e. "select x from y where y.attribute most like known_value). Each join then conceptually becomes a repeated nearest neighbour query with respect to a user supplied metric in a space that can have arbitrarily complex structure.

In this framework, one simply cannot utilize the concept of equality in the way we do in normal database work, because we're not working with equivalence predicates. Not all of the inferences we can make in a fully comparable framework can be made. It might be that some JFIF's and TIFF's will be considered "matching" because the user wished so, but this has little to do with equivalence of values as conceived of in the relational model. For example, it's quite sensible to apply different similarity criteria to joins, updates, deletes and inserts, here.

Sampo Syreeni, aka decoy -, tel:+358-50-5756111
student/math+cs/helsinki university,
openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
Received on Wed Feb 28 2007 - 15:43:26 CST

Original text of this message