Name, NameHistory, NomStatusRel, and RelName 
        To preserve the history of the name editing process, names are
        stored in two tables Name and NameHistory. The Name
        table contains the set of names currently in use by a system. The NameCache
        and FullNameCache fields contain the Latin names without and
        including author strings as calculated from their component fields by a
        trigger functions according to nomenclatural rules valid for a specific
        project. In addition, these cache fields can be used to capture
        preliminary (unstructured) names if needed (e.g. in imports). The NameHistory
        table is structured very similarly with a few exceptions: the name
        string fields preserve their value and AuthorTeam  as well as BasAuthorTeam
        are carrying their respective content as strings and not as a pointer to
        the author tables. A self-referential pointer (SuccNameHistId)
        links a name to its successor within the editing history. An additional
        pointer (CurrentNameFk) gives for every name the name currently
        in use. (N.B.: this does not represent a synonymic relationship, but
        just a history of edits to the name itself). 
        The NomStatusRel table is used to assign one or several nomenclatural status
        values (e.g. 'nom. illeg.' or 'nom. nud.') to a name. The catalogue of
        name status values  for a given project is defined in the NomStatus
        table. To express relations between taxon names considered to be
        nomenclatural rather than a taxonomic opinion the RelName table
        can link arbitrary entries of the name  table. The type of
        this relation (e.g. 'is later homonym of' or 'is basionym for') is
        indicated with a pointer to the RelNameQualifier table. References 
        References of any kind (e.g.
        nomenclatural references, references for taxonomic opinions, factual
        data references) are accommodated in a single recurrent structure reference.
        By using the self referential pointer InRefFk references can be
        defined as part of references in the same table (e.g. article as a part
        of a given book). The type of a reference is indicated with a pointer (RefCategoryFk)
        to the RefCategory table which defines the list of reference types. Since all attributes for the different reference types
        are accommodated in a single entity, a client program hast to decide
        which attributes to use for a given reference category. Trigger
        functions may be used to support this process and to preserve data
        integrity. 
        Citations are created with the RefDetail table which contains a
        pointer to the Reference table and a field (Details) which
        accommodates the exact position in the reference as a string (e.g. page
        number, table number, record id in a database). 
        PotTaxon and RelPTaxon 
        The PotTaxon table’s primary key combines name identifiers with
        reference identifiers (without the reference details). This combination enables the system to preserve
        statements on taxa as they were given in the original information
        sources (e.g. status of a name or distribution information).
        The RelPTaxon table is used to express directed binary relations between any two
        entries of the PTaxon table. This includes taxonomic inclusions
        (i.e. the classification system) and any kind of synonym and concept
        relations. The type of the relation is specified in the table RelPTQualifier
        (as indicated with RelQualifierFk). The source of the
        relationship is indicated by the attribute RelRefFk. 
        Holding all kinds of binary relations in a single table provides a
        convenient and transparent way to query the links between taxa, and it
        greatly facilitates the implementation of client-sided navigation
        functions. 
           |