.pk  D_Identifikationsnummer    a_PNr
          .    D_Geschlecht               a_Geschlecht
          .nn  D_Name                     a_Name
          .nn  D_Name                     a_Vorname
       ref.    E_Person                   a_Vater
       ref.nn  E_Person                   a_Mutter
          .nn  S_Adresse                  a_Hauptwohnsitz
          .    S_Adresse                  a_Zweitwohnsitz

          <--  is target of:  E_Person.Mutter
          <--  is target of:  E_Person.Vater

               |    E_Person                
            ref.nn  E_Organisation             a_Schule

                    |    E_Person                
                    |    E_Student               
                 ref.nn  E_Organisation             a_Studentenheim
                    .nn  D_RaumNr                   a_RaumNr

          .pk  D_Identifikationsnummer    a_ONr
          .nn  D_Name                     a_Name
          .nn  S_Adresse                  a_Zentrale

          <--  is target of:  E_Zweigstelle.Org
          <--  is target of:  E_Studentenheim_Bewohner.Studentenheim
          <--  is target of:  E_Student.Schule

       ref.pk  E_Organisation             a_Org
          .nn  S_Adresse                  a_

 

          .    D_Name                     a_Ort
          .    D_Name                     a_Strasse
          .    D_Hausnummer               a_Hausnummer
          .    D_Postleitzahl             a_Postleitzahl


end of o.student.er1 ERD






How to read the ERD above:



   Prefixes E_, R_, S_, A_, e_ in front of a name show what kind of
   concept the name x in question is denoting:


     E_x    is an entity class. Note however:

            We write e_x instead of E_x where we want to say that E_x is
            occurring in the role of a superclass.

            If a class E_x1 is a specialization of another class E_x,
            i.e. if each instance of E_x1 can be also be seen as an
            instance of type E_x, then e_x is meant to be the group of
            all attributes of E_x1 defined in E_x already (the set of
            all inherited attributes).


     R_x    is entity class E_x representing entity associations that are
            not of cardinality 1:n or n:1 (they need not even be binary
            relations).

     A_x    is an attribute of an entity class, same as a_x() in C++ or
            Java.

     S_x    is a complex attribute (i.e. a set of attributes),
            same as a_x() in C++ or Java.

            We write a_x where we do not care to see whether attribute x is
            complex or not.

     D_x    is a domain, i.e. an attribute type.


     pk     says that this attribute is part of the entity's primary key.

     nn     says that this is a NOT NULL attribute.

     c:     is to mark core entity types (types that do not specialize
            any other type). Types not marked as core entity types inherit
            structure from their - always unique - direct supertype).

            A Core Type is an entity type that is not a specialization of
            another entity type in the model shown.


   Specialisation hierarchies are shown in this form:
   -------------------------------------------------

       |
       E_x3
             |    e_x1
             |    e_x2
             .    E_x3 structure not inherited

   means: E_x3 specializes E_x2 (so that all structure of E_x2 is also
   structure of E_x3). E_x3 is a direct subtype of E_x2, and E_x2 is a
   direct subtype of E_x1.


   Entity Relationship Structure is shown as follows:
   -------------------------------------------------


       E_x1
             ->>  set of E_x2   a_Name


   means: Given any object x1 of type E_x1, x1.a_Name() is an instance of
   a List h_Name defined in the ERD (the Name can be seen as describing the
   role of the list members in relation to x1).


       E_x1
             .    E_x2  x3     (implies:  E_x2  <--  E_x1.x3  )


   means: Each value E_x1.A_x3 is primary key of an entity of type E_x2,
   so that ( E_x1, E_x2 ) is a relation of cardinality (m:1).
   An application may force it to be a relation of cardinality (1:1).


       E_x1
             .    D_x2  x3
             .    S_x2  x3


   means: Each value E_x1.A_x3 is an attribute of type D_x2 (resp.
   S_x2, S_x2 a named set of attributes also specified in this model).

   R_x1 is a type E_x1 that can be interpreted as a relationship type
   of a specific dimension n, 2 <= n.


   Note: Classes E_x without any relation structure  -->  or  <<-  tend to
   be superfluous. They form a self-contained ERD model which quite often
   does not make sense in isolation.

   Here is an example: Classes meant to be enumerations such as e.g.


            E_Category

                 .   A_Value            D_ValueName
                 .   A_Semantics        D_Comment
                 .   A_ObsoleteSince    D_Date


   need usually not exist in form of a separate table. To model it in form
   of a domain D_Category together with an attribute A_ObsoleteSince in an
   E_DomainValues table would be better:


            E_DomainValues

                 .   A_Domain           D_DomainName
                 .   A_Value            D_ValueName
                 .   A_Semantics        D_Comment
                 .   A_ObsoleteSince    D_Date


   To have such a table documenting the semantics of all the values of
   enumeration domains is recommended and definitely helpful (the fact that
   most developers do not create this table is simply bad practice).