Rel359 icon

Rel359


A Relational Database Tool for M359 Students

Limitations

This page explains the limitations of Rel359 and gives some idea of whether or not they might be fixed one day. However, to be honest, I am unlikely to find time to fix any of them!

Domains

  • Rel359 does not support domains, it only supports simple types of CHAR, INTEGER & RATIONAL. If you have installed the Java SDK then you should be able create additional custom types but this has not been tested in Rel359 and is not documented on this site.

Altough the M359 Language uses domains, it never defines them formally, nor does it describe a language for creating them. In fact page 16 of M359 Block 2 states that "a domain is a theoretical construct. We are not, at this point, interested in how a domain might be implemented". Therefore I have no plans to fix this limitation, because there is no definition of what to implement.

Dates

  • Rel359 does not support dates. Dates are treated as strings and therefore don't sort or compare properly unless entered using a format such at ISO 8601 (YYYY-MM-DD).

There is a chance I may investigate whether I can fix this limitation.

Foreign Keys

  • Rel359 does not support foreign keys.

Foreign keys are described in the text as if they are something specific to a given relation and are written in terms of
    foreign key attribute references relation
But page 26 of M359 Block 2 explicitly states that the foreign key "can be matched with any candidate key rather than just the primary key of the relation that it references" and the syntax for foreign keys shown above does not include anything to specify the particular key to reference in the referenced relation so I would argue that it is not possible create an implementation that could correctly reference any key without specifying which key to reference.

Extending the syntax to support foreign keys fully would mean that Rel359 would not be implementing the M359 Langauge, so there seems to be little benefit in attempting to come up with an implementation for foriegn keys when constraints can be used instead. I have no plans to fix this limitation.

Constraints

  • Rel359 only supports a limited number of M359 style constraints. (Currently upto 1000 M359 style constraints are supported.)

In the M359 Language constraints are defined in the context of a relation and are not named but in Tutorial D, they are named. Rel therefore stored the details of the constraints in the a relation and used the name as the primary key. It would have been very complex to try to implement contraints in Rel359 any other way. Furthermore constraints need to be named so that they can be identified if you want to delete them later. Rel359 therefore automatically selects a name when you create a constraint using the M359 Language syntax.

The easist way to provide a unique name for each constaint was to create a relation containing a large number of possible names and then use relational algebra to select a name that hadn't been used already. The downside of this approach is that you can run out of names if you try to create more constraints than there are names in the list of possible names.

This limited number of names for constraints is held in the sys.CandidateNames relation so you can insert additional names should you really need to, but 1000 names should be more than suffcient for the purposes of studying M359. I have no plans to fix this limitation.

Comments

  • Rel359 does not support comments when defining relations.

The M359 Language uses comments defined within braces: {comment text}. Tutorial D and hence Rel and Rel359 use this notation for defining tuples. Using this notation for comments would therefore be difficult and so I have no plans to fix this limitation.

Imperative statements

  • Rel359 requires imperative statements to be terminated with a semicolon.

Requiring a semicolon at the end of imperative statements is an annoying difference between the M359 Language and Rel359's implementation and could potentially mislead unwarey students. However, unlike most of the changes I made to Rel in creating Rel359, this is not just a language change. The semicolon is used to diferentiate between statements throughout the program, from the front end client browser to the database engine, hence changing this feature may be difficult.

One advantage of this feature is that it allows you to create a script file containing several imperative statements separated by semicolons. However there is a chance I may investigate whether I can fix this limitation.

Database backup

  • The Backup button does not work in Rel359.

There is a button marked "Backup" in Rel359 which should save your database to script files so that it can be reloaded later. Unfortunately I forgot about it when I created Rel359 and so it doesn't work but there is a chance I may investigate whether I can fix this limitation.

page last updated: Thursday, December 31, 2015