Rel Project

Rel is an OpenSource project to develop a true RelationalDatabase with a RelationalLanguage that implements and extends TutorialDee. Rel is maintained by DaveVoorhis, and is available on SourceForge at http://dbappbuilder.sourceforge.net/Rel.html

HughDarwen's text, An Introduction to Relational Database Theory, features exercises using Rel. Download the book from http://bookboon.com/uk/student/it/an-introduction-to-relational-database-theory

First-class (FirstClassFunction) anonymous (AnonymousFunction) and higher-order operators (HigherOrderFunction) are a work-in-progress in Rel. See http://dbappbuilder.sourceforge.net/docs/AnonymousAndFirstClassOperatorsInTutorialD.pdf

Releases:

Note: Rel was first released in 2004. Only releases since 2008 are included here.

June 21, 2008: Rel version 0.3.5 Alpha

June 26, 2008: Rel version 0.3.6 Alpha July 11, 2008: Rel version 0.3.7 Alpha July 15, 2008: Rel version 0.3.8 Alpha July 29, 2008: Rel version 0.3.9 Alpha July 30, 2008: Rel version 0.3.10 Alpha

August 1, 2008: Rel version 0.3.11 Alpha August 3, 2008: Rel version 0.3.12 Alpha October 16, 2008: Rel version 0.3.13 Alpha March 25, 2009: Rel version 0.3.14 Alpha

April 14, 2009: Rel version 0.3.15 Alpha

This version of Rel is the first to support user-defined types using TutorialDee syntax. Code like the following now works: 

  TYPE DepartmentName POSSREP {name CHAR};
  TYPE EmployeeName POSSREP {name CHAR};


  VAR Departments REAL RELATION {
    name DepartmentName, 
    city CHAR
  } key {name};


  VAR Employees REAL RELATION {
    name EmployeeName, 
    dept DepartmentName
  } key {name};
POSSREP constraints are supported. E.g.: 

  TYPE posint POSSREP {x INTEGER CONSTRAINT x > 0};
Recursive types are supported (though the syntax for these is likely to change somewhat in an upcoming release, in order to remain compatible with the inheritance model in DateAndDarwensTypeSystem), for example: 

  TYPE stringtree
    POSSREP node {left stringtree, right stringtree}
    POSSREP leaf {string CHAR};


  VAR x INIT(node(leaf('l'), leaf('r')));
  WRITELN x;
However, support for user-defined types is *very* preliminary, is mostly incomplete (inheritance and specialisation by constraint are not implemented yet), and is probably buggy.

Fixes and Features: 

       SUMMARIZE RELATION {TUPLE {a 'A', x 0}} 
          BY {a} 
          ADD ( 
             SUM(x) as xx, 
             SUM(xx) as xxx
          )


     ...or this...


       EXTEND sys.Catalog ADD (
          1 AS p,
          2 AS q,
          EXTEND sys.Catalog ADD (q AS y) AS r
       )


     ...to generate an internal error has been corrected.

May 25, 2009: Rel version 0.3.16 Alpha

This version of Rel includes a number of enhancements, the most significant being preliminary (and undoubtedly buggy) support for single inheritance and specialization by constraint. Constructs like the following may now be explored: 

  TYPE BaseType
    POSSREP {x INTEGER, y INTEGER};


  TYPE DerivedType1 IS {
    BaseType
    CONSTRAINT THE_x(BaseType) = 0 AND THE_y(BaseType) > 5
    POSSREP {a = THE_y(BaseType)}
  };


  TYPE DerivedType2 IS {
    BaseType
    CONSTRAINT THE_x(BaseType) > 5 AND THE_y(BaseType) = 0
    POSSREP {a = THE_x(BaseType)}
  };
An extension has been provided to facilitate experimenting with user-defined types. Types with multiple POSSREPs support an INIT section that can be used to define POSSREPs in terms of each other. This is a possibly temporary mechanism to take the place of "highly protected operators not part of D". (TTM 3rd ed., pg 382, etc.) For example: 

  TYPE blah
    POSSREP blah1 {x INTEGER, y INTEGER}
    POSSREP blah2 {a INTEGER, b INTEGER}
   INIT
    blah1 (a := x * 2, b := y * 2)
    blah2 (x := a / 2, y := b / 2);
A user-defined type with multiple POSSREPs and no INIT section defines a tagged union type. This may be used to create (for example) recursive types. E.g.: 

  TYPE StringTree
    POSSREP node {string CHAR, left StringTree, right StringTree}
    POSSREP nothing {};
Additional enhancements include:

This update also fixes two bugs in DBrowser, the interactive command-line client:

May 31, 2009: Rel version 0.3.17 Alpha

This version of Rel fixes two bugs found shortly after the release of version 0.3.16:

Also, the sys.Operators relvar has been reorganised to capture the implementation versions of operators in a relation-valued attribute. This is experimental, and may change in a future update. To allow for this change, the DatabaseToScript.d script in the Scripts folder has been revised.

December 29, 2009: Rel version 0.3.18 Alpha

This version of Rel fixes several bugs and makes a change to the TYPE semantics to better conform to the model defined in TheThirdManifesto.

1. The supplied batch files for Windows systems referenced parameters as $n (UNIX/Linux syntax) instead of %n. This has been corrected.

2. Creating a relvar using a user-defined Java-based TYPE, e.g., 'VAR TEST BASE RELATION {X Date} KEY{X};' where Date is a 'FOREIGN Java' type, caused an exception. This has been fixed.

3. Given: 

 TYPE DATE POSSREP {c CHAR CONSTRAINT LENGTH(c) = 8 AND IS_DIGITS(c)}; 
 VAR TEST BASE RELATION {ID INTEGER, D DATE} KEY {ID};
The following threw an internal error instead of the appropriate type mismatch error: 

 TEST := RELATION {
    TUPLE {ID 1, D "15061989"}
 };
This has been corrected.

4. In order to more closely confirm to The Third Manifesto's documented model, the implicit tagged UNION construct (a Rel-specific extension) has been removed.

Where this was previously supported: 

 TYPE List  
     POSSREP Node {data INTEGER, next List} 
     POSSREP Nothing {};
You should use this: 

 TYPE List UNION;
 TYPE Node IS {List POSSREP {data INTEGER, next List}};
 TYPE Nothing IS {List POSSREP {}};

February 28, 2010: Rel version 0.3.19 Alpha

This release fixes three bugs.

1. Specifying valid but very large INTEGER literals caused an internal exception. This has been corrected.

2. Specifying valid but very large RATIONAL literals caused an internal exception. This has been corrected.

3. Attempting to select a value of a user-defined TYPE, where the type defines a CONSTRAINT expression that references a user-defined Java-based operator, would always cause a constraint failure if the operator and the type were defined -- and the value selected -- all in the same transaction. This has been corrected.

April 5, 2010: Rel version 0.3.20 Alpha

This version of Rel makes major changes to the type system. It is now possible to create subtypes of the built-in INTEGER, BOOLEAN, RATIONAL, and CHARACTER types. The <, <=, >, >=, =, <>, AND, OR, XOR, NOT, +, -, *, and / symbolic operators have been mapped to named operators, all of which have a name prefixed with OP_. Any 'a + b' is translated to 'OP_PLUS(a, b)', 'a - b' becomes 'OP_MINUS(a, b)', 'a >= b' turns into 'OP_GREATERTHANOREQUALS(a, b)' and so on. This makes it straightforward to create appropriate operators for user-defined types and subtypes, simply by defining new OP_ operators.

At this time, there is a slight overall performance penalty associated with being able to subtype the built-in types, and a noticeable performance hit associated with using subtyping-by-constraint on the INTEGER, BOOLEAN, and CHARACTER types. For teaching purposes (Rel is mainly used as a teaching tool) this shouldn't be a problem. If you're using Rel to run your company payroll, however, the performance hit may be of concern. This version of Rel makes no attempt to optimise performance. As such, it is advisable to do appropriate testing before using this version of Rel in production settings. Future updates will implement appropriate optimisations.

Also, this version is the first to implement TCLOSE. However, it is quite inefficient as it is based on the TRANCLO() example from page 175 of The Third Manifesto, 3rd Edition. However, for teaching-oriented examples and the like, performance should be acceptable.

June 4, 2010: Rel version 1.0.0 Beta

This version of Rel represents an important milestone. It has been updated from 'Alpha' to 'Beta' status and the version number set to 1.0.0. Whilst not yet at a point where it should be used to host the company payroll, the new version number and status reflect that fact that Rel is increasingly stable and usable as a "real" DBMS and not just a teaching tool.

This release includes two bug fixes:

1) RelVar definitions with both a defined heading and an INIT section did not correctly map the INIT expression to the heading if the order of attributes differed. E.g., in the following, company_name and department_name wound up reversed: 

  VAR Department BASE RELATION {company_name CHAR, department_name CHAR} 
INIT (RELATION {
TUPLE {department_name "Research and Development", 
           company_name "General Electronics"},
TUPLE {department_name "Management", 
           company_name "Ads are Us"},
TUPLE {department_name "Management", 
           company_name "General Electronics"}})
KEY {department_name, company_name};
2) In DBrowser, Enhanced mode now correctly displays user-defined TYPE values with relation-valued components. Previously, these caused unpredictable display quirks.

This release also includes one minor enhancement:

1) Given the following: 

TYPE Point POSSREP { x INTEGER , y INTEGER };
TYPE Line UNION;
TYPE Line2p IS { Line POSSREP { p1 Point , p2 Point } };
TYPE LineInfinite IS { Line POSSREP { points RELATION { p Point } } };
An expression like the following... 

RELATION {
TUPLE {x 1, y Line2p(Point(2, 2), Point(3,3))},
TUPLE {x 2, y LineInfinite(RELATION {
TUPLE {p Point(3,4)}, TUPLE {p Point(4,2)}, 
TUPLE {p Point(6,7)}})}
}
...generates a type "not compatible" error because Line2p is neither a subtype or supertype of LineInfinite. Due to user confusion over how to correct this, the error message has been extended to recommend that the user specify an explicit relation heading. E.g., the following will not generate an error because Line2p and LineInfinite are both subtypes of Line: 

RELATION {x INTEGER, y Line} {
TUPLE {x 1, y Line2p(Point(2, 2), Point(3,3))},
TUPLE {x 2, y LineInfinite(RELATION {
TUPLE {p Point(3,4)}, TUPLE {p Point(4,2)}, 
TUPLE {p Point(6,7)}})}
}

July 12, 2010: Rel version 1.0.1 Beta

This version of Rel is a maintenance release.

The following bugs have been fixed:

1) Given a relation with a relation-valued attribute having cardinality 0, e.g.: 

     EXTEND S {S#} ADD (RELATION {TUPLE {S# S#}} COMPOSE SP AS SP_result)
Ungrouping this relation caused a Java exception, e.g.: 

     EXTEND S {S#} ADD (RELATION {TUPLE {S# S#}} COMPOSE SP AS SP_result)
UNGROUP (SP_result)
This has been corrected.

2) A bug in RENAME made it possible to create duplicate attribute names. E.g.: 

     sys.Catalog RENAME (Definition AS Name)
This has been corrected.

3) Due to a bug in the mechanisms that compare values of user-defined types when used in relvar attributes, certain expressions like S JOIN SP JOIN P returned bogus results. This has been corrected.

4) GROUP with multiple AS clauses, or performing GROUP on a relation with relation-valued attributes, e.g... 

     (sys.Catalog GROUP ({isVirtual, Name} as Blah, {Owner} as Blah2))
...threw a Java exception. This has been corrected.

5) DBrowser incorrectly displayed RATIONAL values of NaN, -Infinity and Infinity. This has been corrected.

July 14, 2010: Rel version 1.0.2 Beta

This version of Rel is a maintenance release.

A bug has been fixed in the Rel DBMS. In some cases, the superset operator '>=' did not work correctly. E.g... 

       WITH (S WHERE CITY = 'London') AS S1,
            (SP RENAME (P# AS P#1)) AS SP1:
                (P WHERE
                   ((SP1 WHERE P#1=P#) {S#}) >= (S1 {S#}))
...returned bogus results. This has been corrected.

July 26, 2010: Rel version 1.0.3 Beta

This version of Rel is a maintenance release.

A Java exception could occur when performing a JOIN on relations with common attributes that belong to a user-defined TYPE with at least one relation-valued component. This has been corrected.

September 12, 2010: Rel version 1.0.4 Beta

This version of Rel provides two enhancements and several bug fixes.

Enhancements:

1. Inference of most specific common supertype (excluding Alpha) has been implemented, such that evaluating... 

  RELATION {
    TUPLE {x Triangle(Point(0,0), Point(2,3), Point(7,4))}
    TUPLE {x Square(Point(1,1), Point(4,3))}
  }
...returns... 
  RELATION {x Shape} {
    TUPLE {x Triangle(Point(0,0), Point(2,3), Point(7,4))}
    TUPLE {x Square(Point(1,1), Point(4,3))}
  }
...assuming the existence of types 'Triangle' and 'Square' which are subtypes of 'Shape'.

2. Selectors are now generated for immediate subtypes of built-in types, as per Date & Darwen's "Database Explorations" (ISBN 978-1-4269-3723-1 ), Chapter 21, page 348 "Selectors for System Defined Types". E.g., the following... 

  TYPE PosInt IS {INTEGER CONSTRAINT INTEGER >= 0};
...will automatically create a selector called PosInt which accepts an INTEGER as its sole argument and returns a PosInt value.

Bug Fixes:

1. A derived POSSREP definition list should be allowed to be empty when defining a type whose immediate supertype is a built-in type. However, Rel previously required at least one POSSREP. E.g., the following legitimate definition was not allowed: 

  TYPE PosInt IS {INTEGER CONSTRAINT INTEGER >= 0};
This has been fixed.

2. A bug has been corrected that could, in rare circumstances, cause a database to fail to open due to an internal "LOG INTEGRITY" error.

3. A bug has been corrected that could, in rare circumstances, cause corruption of user-defined type values when inserted into a RelVar immediately after any Rel error (e.g., a syntax error) has been generated.

November 7, 2010: Rel version 1.0.5 Beta

This is a maintenance release featuring two bug fixes:

1. A bug in the way relation literals were parsed allowed the following... 

RELATION {x INTEGER, y INTEGER} {
TUPLE {x 1, z 1}
}
...to be accepted and yield: 
RELATION {x INTEGER, y INTEGER} 
TUPLE {x 1, y 1}
}
This has been corrected.

2. Due to a change in the way the third-party storage engine (Oracle Berkeley Java DB) generated exceptions -- introduced in Java DB version 4.0.71 -- Rel did not correctly handle an exception related to transactions and could wind up throwing its own internal exceptions. This was especially likely when attempting to drop a constraint or relvar immediately after a Rel error message had been generated. This has been corrected.

February 26, 2011: Rel version 1.0.6 Beta

This is a minor release which provides two enhancements:

1. Previously, aggregate operator invocations like the following... 

 SUM(sys.Catalog, CreationSequence)
...could only reference an attribute. The following would not work: 

 SUM(sys.Catalog, CreationSequence + 1)
In this release, aggregate operator invocations may specify an expression. Both of the above expressions will now work.

This change is in accordance with the Tutorial D specification found in Date & Darwen's "Database Explorations - Essays on the Third Manifesto and Related Topics".

2. Short synonyms are now available for some common keywords. RELATION may be specified as REL, TUPLE as TUP, INTEGER as INT, RATIONAL as RAT, and BOOLEAN as BOOL. This is also in accordance with "Database Explorations ..."

Note that DEE and DUM have always been available as synonyms for TABLE_DEE and TABLE_DUM, respectively.

October 19, 2011: Rel version 1.0.7 Beta

This is a minor release which includes the following:

1. Enhancement: New built-in operator GET_UNIQUE_NUMBER returns an integer guaranteed to be unique in a given database.

2. Fix: Given TYPE POSINT IS {INTEGER CONSTRAINT INTEGER > 0}, MAX(RELATION {TUPLE {X 1}, TUPLE {X 2}}, X) failed due to a missing target. Fixed.

3. Fix: A longer default transaction timeout has been set, to reduce the likelihood of spurious timeouts in multithreaded client applications.

4. Fix: A number of bugs that prevented PRIVATE RELATION from working correctly have been fixed.

December 12, 2011: Rel version 1.0.8 Beta

This is a minor release which includes the following:

1. Enhancement: Rel: Error reporting has been improved when Java-based built-in operators fail. E.g., SUBSTRING("blah", 1, 20) used to fail in an un-helpful manner. Now, the error message goes some way toward explaining and locating the problem.

2. Fix: Rel: The following failed with a low-level error; now fixed: 

 var items private relation {id integer, name character} init(
  relation {
   tuple {id 1, name "hi"},
   tuple {id 2, name "lo"},
   tuple {id 3, name "do"}}) key {id};
 var result private relation {r relation same_heading_as(items)} key {r};
 var inner private relation same_heading_as(items) key {id};
 insert inner relation {tuple from items where id = 1};
 insert result relation {tuple {r inner}};
3. Fix: Rel: Updating a relation-valued attribute, as in the following... 
 var x private relation {a integer, b relation {c integer}}
   init (relation {tuple {a 1, b relation {tuple {c 2}}}}) key {a};
 update x where a = 1 (b := update (b) (c := 33));
...caused an error like the following: "ERROR: '%tuple23' has not been defined." This has been corrected.

June 4, 2012: Rel version 1.0.9 Beta

This is a maintenance release which includes the following:

February 26, 2013: Rel version 1.0.10 Beta

This is a significant release, as it implements the latest Tutorial D syntax from Date and Darwen's book "Database Explorations: Essays on The Third Manifesto and related topics" (ISBN 978-1426937231 )

Prior to installing this version of Rel, you must make a backup of your database(s). Then, install this update and load and attempt to execute your backup script(s). If your script successfully loads, you're done. If Rel complains of syntax errors, you'll need to edit the backup script -- based on the "Rel Version 1.0.10+ Syntax" article at http://dbappbuilder.sourceforge.net -- until the script successfully loads.

Changes in this update: 

    EXTEND:
       old: EXTEND r ADD (p AS q, a AS b)
       new: EXTEND r : {q := p, b := a}
    UPDATE:
       old: UPDATE r (p := q, b := a)
       new: UPDATE r : {p := q, b := a}
    RENAME:
       old: r RENAME (a AS b)
       new: r RENAME {a AS b}
    SUMMARIZE:
       old: SUMMARIZE p ADD (SUM(x) AS y)
       new: SUMMARIZE p : {y := SUM(x))
    WITH:
       old: WITH a AS b, x AS y : ...
       new: WITH (b := a, y := x) : ...
    WRAP:
       old: r WRAP ({a, b} AS c, {d, e} AS f)
       new  (r WRAP ({a, b} AS c)) WRAP ({d, e} AS f)
    UNWRAP:
       old: r UNWRAP (a, b)
       new: (r UNWRAP (a)) UNWRAP (b)
    GROUP:
       old: r GROUP ({a, b} AS c, {d, e} AS f)
       new  (r GROUP ({a, b} AS c)) GROUP ({d, e} AS f)
    UNGROUP:
       old: r UNGROUP (a, b)
       new: (r UNGROUP (a)) UNGROUP (b)
    Removed ANY and ALL synonyms for OR and AND.
    Implemented n-adic COMPOSE.
    Implemented XUNION, TIMES, I_MINUS, I_DELETE, 
       D_INSERT and updated INSERT to silently 
       ignore duplicate tuples.

July 17, 2014: Rel version 1.0.11 Beta

This is a maintenance release featuring various enhancements and bug fixes.

Prior to installing this version of Rel, you must make a backup of your database(s). Then, install this update and load and attempt to execute your backup script(s). If your script successfully loads, you're done. If Rel complains of syntax errors, you'll need to edit the backup script -- based on the "Rel Version 1.0.11+ Syntax" article at http://dbappbuilder.sourceforge.net -- until the script successfully loads.

Changes in this update: 

        e.g., VAR myvar EXTERNAL CSV "/home/dave/test.csv";
        e.g., VAR myvar EXTERNAL XLS "/home/dave/test.xls" DUP_REMOVE;
        e.g., VAR myvar EXTERNAL XLS "/home/dave/test.xlsx" DUP_COUNT;
        e.g., VAR myvar EXTERNAL XLS "/home/dave/test.xlsx" AUTOKEY;
        e.g., VAR myvar EXTERNAL JDBC "<host>,<user>,<password>,<database>.<table>,<driverpath>,<drivername>";

      VAR S BASE RELATION { 
        SNO CHAR, SNAME CHAR, STATUS INTEGER, CITY CHAR 
      } KEY {SNO};
      VAR SP BASE RELATION { SNO CHAR, PNO CHAR, QTY INTEGER } KEY {SNO, PNO};
      VAR SPQ BASE INIT(
         EXTEND S: {PQ := RELATION {TUPLE {SNO SNO}} COMPOSE SP}
      ) KEY{SNO};


     UPDATE SPQ WHERE SNO = "S2": 
      {INSERT PQ RELATION {TUPLE {PNO "P5", QTY 500}}};
     UPDATE SPQ WHERE SNO = "S2": {UPDATE PQ WHERE PNO="P5": {QTY := 250}};
     UPDATE SPQ WHERE SNO = "S2": {DELETE PQ WHERE PNO="P5"};

 RELATION  {
        TUPLE { SUPPLIES RELATION {
          TUPLE {PID "P5"}
        }},
        TUPLE { SUPPLIES RELATION {
          TUPLE {PID "P2"}
        }},
        TUPLE { SUPPLIES RELATION {
          TUPLE {PID "P4"}
        }}
 } 
 = 
 RELATION  {
        TUPLE { SUPPLIES RELATION {
          TUPLE {PID "P5"}
        }},
        TUPLE { SUPPLIES RELATION {
          TUPLE {PID "P2"}
        }},
        TUPLE { SUPPLIES RELATION {
          TUPLE {PID "P4"}
        }}
 }
Note: This release includes experimental support for a work-in-progress visual query language called Rev. Using an icons-on-strings data-flow style, it permits constructing queries visually and iteratively, and allows testing sub-expressions whilst constructing a query. To experiment with it, install the Rev package and it will appear as an additional tab in a DBrowser session. To remove it, delete the rev.jar file. Further documentation and video demonstrations will be provided in the future.

October 26, 2014: Rel version 1.0.12 Beta

This is a maintenance release featuring some enhancements and bug fixes. 

   TYPE Temperature UNION;
   TYPE Temperature_Normal IS {Temperature POSSREP {t INTEGER}};
   TYPE Temperature_NoReading IS {Temperature POSSREP {}};
   TYPE Temperature_OutOfRange IS {Temperature POSSREP {}};
   VAR Readings REAL RELATION {timestamp INTEGER, temp Temperature} KEY {timestamp};
   INSERT Readings REL {
    TUP {timestamp 12938, temp Temperature_Normal(33)},
      TUP {timestamp 12940, temp Temperature_Normal(33)},
      TUP {timestamp 12943, temp Temperature_Normal(34)},
      TUP {timestamp 12948, temp Temperature_NoReading()},
      TUP {timestamp 12955, temp Temperature_OutOfRange()}
   };

CategoryDatabase CategoryProject

EditText of this page (last edited October 26, 2014) or FindPage with title or text search