93 Relational Model Correspondence

Predica can recover ordinary relational-model relations as extensions of logic frames. This correspondence is useful, but it is deliberately one-way: it explains how an RM-style relation can be obtained from a Predica frame, not that Predica's primary denotations are RM relations.

The governing picture is:

logic frame  --heading H-->  s-relation extension under H

The relational model lives on the right-hand side of this picture. Predica's logic semantics lives on the left-hand side.

Basic Correspondence

The table is extensional. It describes the s-relation corresponding to a frame. It does not say that the frame has lost its formula, witnesses, path provenance, or result terms.

Relation Variables as Results

In the supplier-and-parts example, the RM relation S is conventionally presented with heading {S#, SNAME, STATUS, CITY}. The corresponding Predica expression can be written as a supplier result:

s.supplier.(id, name, status, city)

In frame notation this is displayed as:

id=I:Integer, name=N:String, status=T:Integer, city=C:String
where ∃S:Supplier (
    s.supplier(S)
    ∧ S.id(I)
    ∧ S.name(N)
    ∧ S.status(T)
    ∧ S.city(C)
)

If each of id, name, status, and city is single-valued for each supplier, the corresponding extension has one s-tuple for each supplier. Under an RM-style heading, those s-tuples are just the rows of S, modulo attribute naming.

If some selected attribute is optional or multi-valued, the correspondence still goes through, but the resulting extension follows the frame. Multi-valued attributes multiply out. Optional attributes with no value contribute no rows when they are exposed as single-valued relation attributes. To preserve an empty predicate extension as a value, expose a set-valued result term instead.

Projection and Restriction

The RM expression:

(S WHERE CITY = 'London'){SNAME}

is recovered by strengthening the supplier frame with a city condition, then keeping only the name:

s.supplier.[city = "London"].name

Displayed as a frame:

name=N:String
where ∃S:Supplier ∃C:String (
    s.supplier(S)
    ∧ S.city(C)
    ∧ C = "London"
    ∧ S.name(N)
)

In the relation view, restriction corresponds to adding the predicate C = "London", and projection corresponds to keeping only name. The city is no longer in the heading, but it remains a witness that justifies the resulting supplier name.

Join as Shared Witnesses

The RM expression:

(SP JOIN S JOIN P){SNAME, PNAME, QTY}

is recovered in Predica by navigating through the shipment witnesses:

s.shipment.(
    supplier.name as sname,
    part.name as pname,
    qty)

The frame exposes the supplier name, part name, and quantity while keeping the shipment, supplier, and part values as witnesses:

sname=SN:String, pname=PN:String, qty=Q:Integer
where ∃X:Shipment ∃S:Supplier ∃P:Part (
    s.shipment(X)
    ∧ X.supplier(S)
    ∧ X.part(P)
    ∧ S.name(SN)
    ∧ P.name(PN)
    ∧ X.qty(Q)
)

In an RM encoding, the same result is obtained by joining SP to S and P using shared key values. In Predica, the shared supplier and part witnesses are already in the frame. The join is therefore not a primitive semantic operation; it is what the corresponding extension looks like after the frame's constraints are satisfied.

Rename and Nested Paths

RM queries often need rename because relation headings are flat. For example, comparing supplier cities with part cities requires two different attribute names in the RM:

( (S RENAME CITY AS SCITY) TIMES (P RENAME CITY AS PCITY) )
WHERE SCITY > PCITY

In Predica, the comparison can be written against paths before choosing a flat result heading:

s.(supplier, part).[supplier.city > part.city]

If the two cities are to be exposed as relation attributes, the frame chooses distinct result labels:

s.(supplier, part).[supplier.city > part.city].(
    supplier.city as scity,
    part.city as pcity)

The result labels scity and pcity belong to the frame result. The paths supplier.city and part.city belong to the frame that produces the extension.

Where the Correspondence Stops

The correspondence is exact only for the chosen result heading. Two different frames can have the same s-relation, so equality of RM-style extensions is not equality of Predica denotations. The frame still records the result terms, free variables, and formula that produced the extension.

The correspondence is also heading-relative. The same frame can be materialised under different headings, producing different s-relations. Complement and universe are additionally domain-relative: an implementation must know which value domains are being used for the heading.

Finally, an implementation may avoid materialising the s-relation at all. It may use symbolic frames, indexes, m-relations, or other factorised structures. Such representations are valid only to the extent that their externally visible behaviour agrees with the frame semantics. For m-relations, the specific test is heading-relative expansion:

M is valid under H  iff  M!_H is the intended s-relation extension