Generic Entity Relationship Model
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.


Generic Entity Relationship Model (GERM)

This system allows the definition of attributes, entities and relations as used
in entity-relationship (ER) models. It will then handle input and
representation of data appropriately.

The following actions are currently implemented: list, view, edit, delete and
submit. They correspond to the SQL commands SELECT, SELECT ... WHERE, UPDATE,

The system also provides a framework for the implementation of a user interface
that will then be able to trigger various actions on specific entities. An HTTP
interface using HTML to represent and input data is available.

Furthermore, GERM provides an integrated privilege system. Apart from security
reasons this is also necessary for a complete constraint specification and to
ensure integrity of the data. The user interface should try not to provide any
illegal actions to spare the user annoying 'permission denied' errors. The idea
is to hide information that's irrelevant to the user.

Consider the following example of a tournament planning system:

There is a number of tourneys available. For each tourney teams can be formed.
Each tourney requires a specific number of team members. In a real situation,
the user may not be able to join a particular team for various reasons. For
instance, the system should prevent the user from joining a team if he is
already a member of a team that partakes in the same tournament. Furthermore,
the limit for the number of team members must not be exceeded. Also, it should
not be possible to join a team if the tournament has already started or if it
is already finished. The system might want to check that the user has paid the
entrance fee before allowing to join a team, etc.

Each of these conditions can easily be ensured by defining the appropriate
relations and constraints. This information can then be used to determine if a
menu entry should be made available to the user depending on wether or not the
user is currently able to join _any_ team at all.

o Programming Language: Python 2.3
o Libraries: Python DB Libraries, Apache mod-python (for HTTP user interface),
  Tcl/Tk (for Tcl/Tk user interface)

o Databases: Currently, only MySQL, any with Python database API support in the

o OS platforms: Any supported by Python and the required libraries

o Features:

  - Ensures data consistency by resolving relations and constraints.
  - Generates appropriate input forms.
  - Object-oriented implementation to be easily extensible and flexible.
  - Separates data related and user interface related (i.e., data input and
    output) code.
  - Seperates generic data related code (like dealing with relations,
    contraints, permission) and code related to specific data (like the
    generation of games for a tournament).

o Technical Problems:

  - Handling all data in a generic way and still provide all kinds of possible
    requirements to complex data structures.
  - Providing extensibility and flexibility for the programmer while still
    being easy to use and adapt to the needs of an end user.

o Solution specific to a particular web site:

  Even though this system was designed with a particular application in mind
  (i.e. a LAN Party and Tournament Planning System), it was not intended to be
  specific to this use.

o Services:

  I plan to host a demonstration of the system. The basic features of the
  system are implemented and I have a testing application running on my
  I plan to provide a forum for development of the system.

o Differences to other CMSs

  GERM is really more of a library than it is a complete system. It needs a
  rather low-level description (essentially, an entity-relationship model) of
  the data it is supposed to manage. It has many more possible uses than just a
  news or message board. I even consider using it for an accounting program.
  Other CMSs also seem to be restricted to the Webserver/Browser environment.
  To GERM, that's just one possible user interface.

Clemens Buchacher, 2005-08-26