Types and Identifiers
Almost all elements in an ERL document have a mandatory
identifier. For the erl, ent, rel and
attr elements, moreover, the identifier
is bound to be restricted: it must start with an
alphabetical character and must be entirely formed by alphanumerical
characters. Case sensitivity cannot be guaranteed, as it depends on
the underlying database, but ERW is case
sensitive, so be careful. Note that the identifiers
id, file, owner,
share and belongs are
reserved.
 | You can use identifiers of any length, but they will be combined during the reification process to get the actual name of database columns representing references to other tables. If you use too long identifiers, this construction could yield names that exceed the maximum identifier length in your database. Try to use short, meaningful identifiers. |
All attributes have an ERL type. ERL types include the following SQL types:
| CHARACTER | CHARACTER LARGE OBJECT |
| CHAR | CLOB |
| CHARACTER VARYING | NUMERIC |
| CHAR VARYING | DECIMAL |
| VARCHAR | DEC |
| NATIONAL CHARACTER | INTEGER |
| NCHAR | INT |
| NATIONAL CHAR | SMALLINT |
| NATIONAL CHARACTER VARYING | DATE |
| NCHAR VARYING | TIME |
Moreover, there is an additional simulated type, BOOLEAN, which holds a truth value[1], and TEXT, which is a non-SQL, but largely diffused, variant of CLOB. All SQL types are faithfully preserved during reification, whereas BOOLEAN is mapped to CHAR(1) (the column will hold '0' or '1').
Finally, there are two virtual types: enum and fset. They were added to increase the expressive power of an entity-relationship schema described in ERL and avoid the creation of many relationship types with the sole purpose of simulating data types.
The enum type
Often in databases one has to store one out of a finite set of values. These values may be fixed forever (e.g., weekdays, male/female, …), or could vary over time (e.g., positions in a company).
To this purpose, ERW provides two solutions by means of the
enum type and of the enum
element. The enum element specifies an
SQL type and describes a list of value/label pairs. Any attribute of
type enum pointing by means of the enumref attribute to a certain enum element will have the SQL type of that
element; moreover, the content of the attribute is restricted to the
values described in the enum element
and, for each value, the user will always be presented with the
corresponding label. In such a case we say that we defined a
static enumerative attribute.
If, on the other hand, there is no enumref in an attribute with type
enum, then a special table is created that holds the
value/label pairs. The value/label pairs can be edited by authorised
users, and so we speak of a dynamic enumerative
attribute. Clearly this kind of enumerative attribute is
more flexible, but also less efficient.
The fset type
Filesets are a rather sophisticated object (in fact, a weak entity type) camouflaged as an attribute. An attribute of type fset does not generate an SQL column: instead, it generates another table that holds information about files associated to entities. When editing an entity, the user will be able to upload and download files, associating them to the entity much like a weak entity.
As an additional facility, files in a fileset may have attributes
(for instance language, or a title). To obtain this result, a fileset
type defined using the fset element
must be referred using the fsetref
attribute. Of course you cannot use the fset type when
defining the attributes of a file set.