Shoji — RNT

Query by example for RNT, and the only subsystem with no syntax to learn. Shoji opens a relation as an empty skeleton, a window with its heading and a blank row, and you ask a question by filling the blanks in with what an answer would look like.

-- which suppliers in London ship part P2?
S  | SNO | SNAME | CITY
   | _s  | P.    | London

SP | SNO | PNO
   | _s  | P2

= | SNAME
  | Smith
  | Clark

Why a shoji

A shoji is a sliding screen: paper panes held in a wooden lattice, a grid you can almost see through. A skeleton is the same thing. The lattice is the relation’s heading, the panes are blanks, and whatever you write in a pane says what you are looking for.

Skeletons

The example above asks for the suppliers in London that ship part P2. The two skeletons are all you fill in; the last window is the answer Shoji opens, Smith and Clark from Date’s suppliers and parts. Nothing you typed is a keyword. Each pane holds one of a few kinds of entry:

Entry	Means
`London`, `P2`, `300`	a constant: the row must have this value
`_s`	an example element, underlined on screen: any value, but the same one everywhere it appears
`>200`, `<>London`	a condition
`P.`	print: show this attribute in the answer
`G.`	group by this attribute
`CNT.`, `SUM.`, `AVG.`	an aggregate over the group

The notation is Moshé Zloof’s, from IBM’s Query-by-Example in the 1970s, and it has hardly needed to change. An example element is how two skeletons join: _s appears under SNO in both windows, so the supplier and the shipment must agree.

When a condition needs more than one pane, it goes in a condition box:

-- who ships between 200 and 400 of some part?
SP | SNO | PNO | QTY
   | P.  | _p  | _q

CONDITIONS
_q > 200 and _q < 400

= | SNO
  | S1
  | S2
  | S4

Changing things

The leftmost pane of a row, under the relation’s name, holds a command for the whole row: I. inserts, D. deletes, U. updates. A row with a command and constants is a change; a row with a command and example elements changes every row the examples match.

S  | SNO | STATUS
U. | S1  | 30

SP | SNO | PNO
D. | S4  | _p

A skeleton with I. and empty panes is a form. Every relation has one, so people who never write a query can still put data in, and the integrity rules of every other subsystem still apply to what they enter.

Your own skeletons

A window can be given a heading of your own. Fill it with I. and example elements from the other windows, and the answers become a new relation:

S     | SNO | SNAME
      | _s  | _n

SP    | SNO | QTY
      | _s  | >300

HEAVY | SUPPLIER
I.    | _n

HEAVY is published under \relation, and Shoji keeps the question that made it, so it can be asked again.

Skeletons are relations

A saved question is stored the way it looks: one tuple per filled pane, in PANE (QUESTION, RELATION, ROW, ATTRIBUTE, ENTRY). So the questions people have asked are themselves something to ask about:

PANE | QUESTION | ATTRIBUTE
     | P.       | CITY

That is every saved question that looks at a city.

In the same runtime

Any relation opens as a skeleton, whoever made it. Open EGG to see Aleph’s open promises, open STACK and you are looking at a running Forth machine, open a Dandelion bundle and its answers are rows like any others.

EGG | PROMISE     | LAID
    | orders-ship | P.

-- from pureSQL: what the HEAVY window found
SELECT SUPPLIER FROM HEAVY;