In principle, data can be classed into so-called "entities". These are classes of data that show each a particular kind and number of specific features. So, the cities Trento, Innsbruck and Lucerne can form for example a class "places" which is characterised by the features "place name", "degree of longitude", "degree of latitude", "state" and "number of inhabitants". The single members of such a class differ from each other in the different values of the features that characterise this class.
In a relational database, each entity is ideally saved in an own table with the values of one specific feature in each table column. The table rows contain the the individual members of the data class (entity). In most cases – also in VerbaAlpina -, a relational database represents a collection of different entities (and hence tables) between which there a logical relations. So, the entity "informant" which is defined by the features "age", "sex", "birthplace" and "place of residence" is linked logically to the entity "places" in such a way that the values of the features "birthplace" and "place of residence" have a correspondence in the entity "places". Relations between members of these two entities result from the concordance of the features' values in each entity, which are congruent in their nature. In this case, there could result theoretically an assignment from identical values of the features "birthplace" and "place of residence", by which the geographical coordinates of the birthplace could be assigned indirectly to an informant. Looking at this specific example, one can easily recognize that problems could arise due to homonyms. To avoid such problems, integral numbers are usually applied as identifiers (briefly: "ID") that mark the members of an entity unambiguously.
This system of entities and their logical relations, which was sketched above, is called entity-relationship. The data stock, which is stored in a relational database can hardly be understood and used without any explanation of the dependences between the data within the database. Usually, entity-relationship is illustrated in form of a graphic scheme.
The entity-relationship is subject to permanent adaptations (and hereby changes) during the cyclic development phases of VerbaAlpina (cf. Versioning). Each filed version of VerbaAlpina will be stored with the the corresponding entity-relationship model of the underlying database version in form of an ER diagram. This diagram is created using the program yEd and saved as (GraphML) and as PDF document. The following chart is based on the entities and links of the database VA_XXX as it was on 20/03/125, but it does not reproduce it completely and has to be understood as illustrating example:
