Overall System Design
ERW is a complex system with many interrelated components, so before starting to describe in detail each part it is a good idea to review a bit more technically the procedure to generate and manage a database using it.
The first and most important step is the creation of an ERL file. ERL is a simple XML-based language that describes entity-relationship schemata decorated with additional information pertaining the actual database structure (such as the SQL types of the attributes) and some editing information (such as which relationships can be edited in an entity form). ERL has also support for simulated SQL types, that is, additional types that you can use as if they where actual SQL types. They include, for instance, boolean and enum.
Then, you have to create your database. This is accomplished using ERtool, a tool written in Java™ that reads ERL files and produces a number of outputs. The first usage of ERtool is to generate SQL code creating the actual database. Note that in this phase ERtool has to reify the entity-relationship schema, that is, to decide how to implement in the relational model the entity-relationship schema given in the ERL file (ERtool can also generate documentation on the reification process, so you can really know what it's doing).
Assuming that you installed ERW correctly (which includes configuring PHP and Apache), you now have to generate the definition files: these are PHP files that contains information about the database. They are essentially a reworking of the data contained in the original ERL file. The definition files are read by the PHP scripts of ERW's run-time environment to produce the actual forms.
Definitions files are again generated by ERtool using the ERL file, and should be moved in a place where the run-time environment can find them (to this purpose there is a configuration variable that can be set).
Other configuration variables let you choose the type of DBMS, localisation features, and so on. Once everything is set up, your are ready to edit the database. You should provide a method to access the editing scripts with the right URL. A sample file, index.orig.php, can be used as a first try.
There are however several things that you could not like in the forms thus created. For instance, if you have a two-elements enumerative type (say, male or female) you could prefer a radio button to a drop-down menu. Or you could not like the way an element is labelled (by default, using its first attribute). For such things, ERW lets you write custom files, which alter some of the data of the definition files so to tune the user interface to your needs. Custom files also allow you to implant hooks in the run-time environment so that you can, for instance, do some post-processing after every database modification.[1]
If you need more flexibility in the user interface, custom forms can be used to provide a highly customised appearance. Custom forms are written in an XHTML-like language, so you can use style sheets, etc.
Finally, you may want to change the structure of your database. From the user interface viewpoint this can be done in a breeze, as it is just a matter of modifying the ERL file and regenerate the definition files. However, the changes to the database structure must be handled manually. Usually it is a good idea to keep a copy of the previously generated SQL statements and see the differences. In any case, simple changes such as adding or removing attributes, entities and relation are almost effortless, and the checkdb.php script can help you by pointing out discrepancies between definition files and SQL tables.
Entity-Relationship Schemata
To understand each other throughout the rest of this manual, we have to set up a minimal common language. Unfortunately, many terms in the database world are not completely standard, and can vary depending on the textbook you have. A radical choice made in this manual is to replace, whenever possible, database-related names for sets and functions with the more standard and more stable terms used by mathematicians. If you never heard of entity-relationship schemata (or of their graphical counterpart, entity-relationship diagrams), however, we suggest you to have first a look at a good textbook on the subject.
Entities model things of the real world. In our library example, a (specific) person and a (specific) book are both entities, because these are the things we want to model (we could call entities "things", but this would not sound very scholarly). Each entity has a type. Entity types model concepts: in our example, entity types will be person, subscriber and book. To an entity type we associate usually a set of attributes, that is, pieces of information: the book title, the person name, the subscriber donation and so on. Each entity defines a value for each attribute of its type (e.g. for each person there must be a name).
Relationships, on the other hand, model connections between things. For instance, a book may be on loan (or have been lent) to a person or not. Also relationships have a type, and may have attributes: for instance, the start and end date of the lent.
An entity-relationship schema is a directed[2] graph whose nodes are entity types, and whose arcs are relationship types. In other words, a schema is given by a set of entity types and a set of relationship types, where each relationship type is assigned a source entity type and a target entity type. In our example, the set of entity types is { person, subscriber, book }, whereas the set of relationship types is { loan }. The relationship type loan has source entity type person and target entity type book.
An instance of an entity-relationship schema is a sort of abstract database. It is given by a set for each entity type (called an entity set), and a multirelation[3] for each relationship type. Not surprisingly, elements of the set associated to an entity type are called entities, and elements of the multirelation associated to a relationship type are called relationships.
A multirelation is an extension of the mathematical concept of relation; in a multirelation from a set X to a set Y two elements can be in relation "more than once". Mathematically, a multirelation from the set X to the set Y is a set R (the support of the multirelation) equipped with two legs [4], that is, two functions R0:R → X and R1: R → Y. A multirelation should be interpreted as follows: if there is an element r of R such that R0(r)=x and R1(r)=y, then x and y are related (once). But if there is another element s of R such as R0(s) and R1(s)=y, then x and y are related twice, and so on. If there are no elements of X and Y that are related twice, then R is a standard relation. It will be useful in the following to note that given a multirelation R from X to Y, we can build a multirelation RT, called the transpose of R, going from Y to X, simply exchanging the rôle of R0 and R1.
Getting back to entity-relationship schema instances, we note that if a relationship type goes from an entity type instantiated in a set X to an entity type instantiated in a set Y, then the multirelation instantiating it must go from X to Y.
In our example, an instance of the database specifies a set of persons, a set of subscribers, a set of books and a multirelation for loans. Each loan (i.e., each element of the support of the multirelation) has an assigned person and book, and, of course, the same person can borrow the same book several times (so we really need a multirelation).
Finally, an instance of an entity-relationship schema specifies for each entity set and multirelation a function that assigns to each element its attributes. A precise definition of this function would require a precise definition of the attributes and of their Cartesian products, and it is beyond the scope of this section.
Getting it all together: entity-relationship schemata are a syntax that allows you to model some real-world objects and their connections. Each schema has, however, a semantics: its instances. The purpose of a database managed by ERW is to store an instance of an entity-relationship schema and let the user modify it.
 | The discussion above may have bored some reader, but it is necessary because ERW implements on the top of a standard SQL database the multirelational semantics of entity-relationship schemata described in "Multirelational Semantics for Extended Entity-Relationship Schemata With Applications", Proc. of ER 2002, Lecture Notes in Computer Science, Springer-Verlag, 2002. This semantics is much more precise and natural than the "tuple semantics" of relational databases, and in fact it is a good idea to think of relational databases in set-theoretic terms whenever you can. |