Tutorial Dee

Tutorial D

A RelationalLanguage by HughDarwen and ChrisDate. It is used for many of the examples in ChrisDate's AnIntroductionToDatabaseSystems, and is fully described in TheThirdManifesto. Unlike StructuredQueryLanguage, it is truly relational. The result of a query is always a set, never a bag like in SQL. As its name suggests, it is primarily intended for teaching purposes.

It is important to distinguish between D and Tutorial D. Also not to be confused with DeeLanguage.

Tutorial D is a suggested notation for teaching the concepts within the TheThirdManifesto and the authors' other books. It does not yet have a complete implementation, but Rel (below) is probably the closest.

D is any database language that conforms to TheThirdManifesto's Prescriptions and Proscriptions -- a set of guidelines for a database language that exhibits certain desirable characteristics. For example, TheThirdManifesto's RM Prescription 26 states "D shall be constructed according to well-established principles of good language design."

Why the letter "D" was chosen is unspecified (obvious guesses are "Database", or a tongue-in-cheek database oriented successor to CeeLanguage), but Hugh Darwen has retroactively fitted it to "Date and Darwen's Database Dream".

As of this writing, there are at least 6 implementations of D:

D4: http://www.alphora.com (DataphorIsOpenSource now http://dataphor.org/))
D flat: http://www.hughdarwen.freeola.com/TheThirdManifesto.web/REAL.pdf
Duro: http://duro.sourceforge.net/
Rel: http://dbappbuilder.sourceforge.net/Rel.html -- RelProject
Dee: http://www.quicksort.co.uk -- Python + relations

Of the above, the RelProject is the most faithful implementation of TutorialDee, but is still a WorkInProgress.

Commentary

Tutorial D is the training language in recent Date's books. It tends to look like:

(tableA operator tableB) [column1, column2, etc...]

I think I prefer prefix {"op (a, b, ,8...)"} notation instead of infix {"(a op b)"} for relational logic. That way you don't have a totally different syntax if there are 3+ operands instead of just 2 required for infix. I suppose this is probably a subjective thing though.

However, it is easier to implement prefix in most other languages since user-defined functions usually support prefix, but not infix. Thus, one could train with or simulate a RelationalDatabase in their local computer language more easily with prefix.

I don't like the nesting approach of Tutorial D and SQL. I like the functional style of BusinessSystemTwelve.

Tutorial D has the WITH statement if you prefer not to nest your statements. For an example, see page 17 of this paper - http://www.hughdarwen.freeola.com/TheThirdManifesto.web/Missing-info-without-nulls.pdf

-- PaulVernon?

PageAnchor prefix_vs_infix

I don't like the nesting approach of Tutorial D and SQL. I like the functional style of BusinessSystemTwelve.

I don't understand "the nesting approach", nor what it might be that Tutorial D and SQL have in common but Tutorial D and BS12 do not have in common. But I assume that "the functional style" here refers to BS12's prefix notation. Date and I chose it because we thought it was better for teaching purposes, but we have had cause to regret it and would probably switch to prefix notation if we could start again from scratch.

-- HughDarwen

Is it too late to change?

(More syntax critiques under TqlDesignGoals)

I think by nested he is talking about the fact that everything is nested inside the one statement. In SQL, you would say (MS SqlServer):

        /* show departments that exceed their salary budgets */
Select d.Deptnum, Count(1) as Emps, Sum(e.Salary) as Salsum
From Emp as e
Join Dept as d
On e.Deptnum = d.Deptnum
Where Salsum > d.Budget
Group By Deptnum

This is nested because all of the logic is nested within the statement.

BS12 would use the following (taken from the above link).

  [DEFINE] T1 = JOIN(EMP, DEPT)
           T2 = SUMMARY(T1, GROUP(DEPTNUM), EMPS=COUNT,
                SALSUM=SUM(SALARY))
           T3 = SELECT(T2, SALSUM > BUDGET)

[Subject to frequent TabMunging. I think there's also an error in the original source. The first two commands should be switched or reworked in order to get BUDGET properly from DEPT.]

What I think he is really referring to is the use of temporary variables T1, T2 and T3.

In SQL there are references being created, such as 'Dept as D', but these are embedded within the statement. With the BS12 format it is much easier to look up what T1 or T2 actually mean.

However, I don't think the functional style reveals the queries structure as easily.

Please clarify

Also, with a database you tend to get to know the schema rather well. The use of temporary variables can hide this from you, especially if names are inconsistent.

Please clarify.

I think this is a question of taste rather than a limitation in SQL or Tutorial D itself.

The style of functional programming has been available in TSQL for some time, but the nested format is still preferred for most small queries. Personally I prefer the nested style.

-- Ged Byrne

You are right, it is largely a matter of taste. But note that a functional style can be nested also. Thus, we are not losing that ability, but gaining reference-based chunking when things grow large. Temporary references/views are merely a bonus, for each statement can be nested inside if need be (at least in TQL/SMEQL). Plus, not all duplication of reference is tree-shaped. Named references allow non-tree reuse of sub-queries, unlike nesting. Further, we already have SQL if you like a nested standard. Any new query standards should take a different direction from SQL to provide more style choices.

I agree that for small queries, the nested style is fine. However, for large queries they are a nightmare in my opinion. For one, it is tough to factor out duplication of the tree "nodes". Function references can be proven to be more general-purpose than nested trees. Plus, it is easier to test the functional style because you don't have to bring the top and bottom "bread" together if you want to test the outer-nested queries by themselves. Further, a functional style does not preclude nesting: you simply nest the functions if you want. Thus, it easily gives you both. Finally, most programmers will better relate to functions I suspect.

-- AnonymousDonor

TutorialDee doesn't preclude factoring out portions as functions. In fact, it explicitly allows for relation-valued functions. I agree that this is a very useful technique. -- DanMuller

In addition to implementing a significant subset of TutorialDee, The RelProject implementation of TutorialDee adds syntax enhancements. One of these is the ability to produce relational expressions without the "nesting" noted above. I'll take "nesting" to mean a tendency toward a rather LISP-like frequency of parentheses. For example, the TutorialDee expression:

((S {a, b}) WHERE b = 3) RENAME b AS q

Can be written in Rel as:

S {a, b} WHERE b = 3 RENAME b AS q

Or even:

S {a, b} [b = 3] RENAME b AS q

The Rel precedence rules for relational operators are simple and fairly intuitive.

I suppose it's a matter of opinion as to whether these are "enhancements" or not.

-- DaveVoorhis

I don't have either of those books, so I'm not really familiar with Tutorial-D (or any of its variations). I am, however, familiar with SQL. For comparison's sake, what does something in SQL look like relative to Tutorial-D? -- JonathanMitchem

See QueryLanguageComparison

Regarding Example 5:

Is there any case where we would not be inserting a TUPLE? I.e. could this TUPLE word here be dropped in a non learning version of Dee?

Could it be dropped? Certainly. Even if you were inserting things other than TUPLE it could be dropped (using keywords only for those other things). And you'd be better off going back to something closer to the 'myThings(a,b,c,name)' solution SQL provides to reduce verbosity and improve clarity - at no loss of generality or 'purity'. Perhaps:

   myThings U= relation(a,b,c,name) { (1,2,3,'glub'), (4,5,6,'glob') };
     or
   myThings = union(myThings,relation(a,b,c,name){(1,2,3,'glub'),(4,5,6,'glob')}).

The extreme and unnecessary verbosity of languages like SQL and TutorialDee are almost enough to make me run away screaming and reject RelationalModel due, merely, to associative aversion. If you're aiming for a terse version of D language, you could do so much better than taking TutorialDee and trimming it down. Start from the other direction: grab the list of all the RelationalOperators? provided by TutorialDee, and simply create a nice, terse syntax that covers all of them and is reasonably intuitive, prioritizing operations that you profile/guess will receive the most use. Just be sure to also consider failure-states (e.g. missing punctuation should probably fail-fast or self-correct easily rather than create a correct command that does something that wasn't intended).

Well of course we won't reject the relational model due to a specific language which talks to the RDBMS. I don't mind the verbosity for teaching - and it is good that they make the distinction between Dee and TutorialDee. Not that I'm wanting to turn a relational language into a regex or a perl style language - but cutbacks and careful syntax choices can be made so that it is more practical for real world developers. If we look at history, we've seen Standard Pascal, Modula, Oberon, fade into academic obscurity due to even their verbosity as a primary reason possibly. We've seen Ada being mocked and rejected due to its complex, verbose, baroque syntax - although Ada has been successful in aerospace.

I see the inventors of TutorialDee brag about how they got rid of SELECT as if this is a big step for man in a PDF file somewhere (possibly they brag because SELECT is too imperative, and/or that it adds needless verbosity).. but in some of the other syntax in TutorialDee such as this TUPLE repetition I noted, I find it just as verbose and sinful (or so similarly verbose to SQL that people will pass it off as an SQL clone that's just a different way of accessing the database in a different language without it providing lots of serious benefits (even if it does provide some)). I see some NeedlessRepetition in many examples, which can be reduced I'm sure.

So let's see:

 put myThings rel {
{x: 1, y: 2, z: 3, name: 'glub'},
{x: 4, y: 5, z: 6, name: 'glob'},
 }

That's still a bit verbose since we repeat the x, y, z. INSERT is trimmed to PUT keyword and no caps lock is used. RELATION is trimmed to REL. Put could be changed to ins short for insert.

Or similar to your example:

   put myThings 
   rel(x, y, z, name) { 
      (1, 2, 3, 'glub'), 
      (4, 5, 6, 'glob') 
   };

Didn't D used to use square brackets for column selection?

[D is an abstract specification. It doesn't "use" any syntax. TutorialDee does not, nor has it used square brackets for projection. DeleteWhenRead]

On page 151 of "Introduction to Database Systems" by C. J. Date does indeed show and even mention square brackets. I don't know if that was meant to be "Tutorial D" formal, though.

Which edition? I'm looking at page 151 of the 8th edition, and I see no brackets of any kind. The only code on my page is a SQL query.

6th edition. A bit dated (no pun intended). Outdated textbooks are really cheap because of the huge volume dumped on the market after professors move on.

http://www.dcs.warwick.ac.uk/~hugh/#CS252

This contains course notes for a course taught by HughDarwen. It teaches a great deal of Tutorial D. This is the closest thing I can find to a "tutorial" online.

Whole bunch of stuff moved to DateAndDarwensTypeSystem

CategoryProgrammingLanguage CategoryDatabase CategoryQueryLanguage