A fundamental purpose of a database is to represent abstract values, such as dates, colours, circles or polygons.
Often a tuple is used for an underlying representation of a value of a given type. For example, a circle can be represented in terms of a tuple that records centre and radius attributes. Chris Date & Hugh Darwen (henceforth referred to as D&D) use the term possrep for this concept (as a reminder that there can be more than one possible representation of a value).
D&D have chosen not to formalise a possrep using the notion of a tuple - probably to avoid confusion between the representation and what is being represented. That is certainly important, but nevertheless it is convenient to think of a possrep as involving an underlying tuple representation. Note therefore that where D&D speak of possrep components, we might equally call them attributes, which is the terminology used for members of tuples.
For a given data type there is a defined set of allowable values of that type. For a given possrep, this in turn means there is a defined set of possible values of the tuple used to represent the value. This set of tuples (which may be infinite) is the extension of a predicate expressed on the possrep components called the possrep constraint.
The extension of the possrep constraint is a relation but it should not be confused with a relation recorded in a database. Instead we are talking about a relation which represents the constraint and normally has an intensional definition.
We consider a relational database to essentially be a database variable (dbvar) which holds a database value (dbvalue) of some database type (dbtype).
We formalise a database schema (dbschema) as a possrep of a dbtype. The representation involves a tuple with relation-valued attributes. We will follow the convention of referring to the components of the possrep as relvars even though it isn’t really appropriate to assume they are variables when one is considering the components of a dbvalue.