WissDB . since Jun 15 . Index . DOCs TOP TOC

WissDB: The Logical Data Model

Because the preceeding section did not allow any redundancy in the specification, we now show the result in terms of a complete Entity Relationship Model.

Notation semantics are explained at the end of this diagram (the diagram is given in form of text derived automatically from the formal data model specification in section 2. It is object oriented in as far as the description of an entity type is always embedded into a section showing in detail also all its super- and subtypes.

The description of an entitiy type includes all structure of that type, i.e. attributes and  relationships).

c:   E_DomainValues

          .pk  D_DomainName            a_DomName

          .pk  D_ValueName             a_DomValue

          .nn  D_ValueNumber           a_ValueAsNr

          .    D_Comment               a_Semantics

          .    D_Date                  a_ObsoleteSince

c:   E_Process

          .pk  D_Locator              a_Loc

          .nn  E_KnowledgeItem        a_Description

          .    E_Role                 a_Role

          <-- can occour as:      E_Result.of

c:   E_Role

          .pk  D_Locator              a_Loc

          .nn  E_KnowledgeItem        a_Description

          <-- can occour as:      E_Process.Role

c:   E_KnowledgeItem

          .pk  D_Locator              a_Loc

          .nn  D_ItemType             a_Type

          .    BLOB                   a_NodeValue

          <-- can occour as:      R_Is_keyword_for.for

          <-- can occour as:      R_Is_related_to.B

          <-- can occour as:      R_Is_related_to.A

          <-- can occour as:      E_Role.Description

          <-- can occour as:      E_Process.Description

          |

          E_Result

               |    e_KnowledgeItem     

               .nn  D_ViewType             a_View

               .nn  D_AbstractionType      a_Abstraction

               .nn  D_UsageType            a_Usage

               .    E_Process              a_of

               |

               E_Practice

                    |    e_KnowledgeItem     

                    |    e_Result             

                    .    INT                    a_PracticeType

                    .    D_Counter               a_reuse_0

                    .    D_Counter               a_reuse_1

                    .    D_Counter               a_reuse_2

                    .    D_Counter               a_reuse_3

          |

          E_Candidate

               |    e_KnowledgeItem     

               .nn  D_EMailAddress          a_from

c:   R_Is_related_to

          .pk  E_KnowledgeItem        a_A

          .pk  E_KnowledgeItem        a_B

          .pk  D_CorrelationType      a_Correlation

c:   R_Is_keyword_for

          .pk  E_Aspect               a_keyword

          .pk  E_KnowledgeItem        a_for

c:   E_Aspect

          .pk  D_Locator              a_Loc

          <--  can occur as:          R_Is_keyword_for.keyword

c:   E_Alias

          .pk  D_ProjectLocator       a_Nr

          .    D_Locator              a_Loc

   Notation Semantics:

   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 attribute must be NOT NULL.

     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 [?] spezializes 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      (to be read as:   <-- E_x2 [?] .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) or (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 set of attributes such that records of type S_x2 [?] make

   sense in themselves).

   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 relation structure  -->  or  <<-  tend to

   be superflous. 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 the

   table E_DomainValues would be better:

            E_DomainValues

                 .   A_Domain            D_DomainName

                 .   A_Value             D_ValueName

                 .   A_Semantics         D_Comment

                 .   A_ObsoleteSince     D_Date

For WissDB it is mandatory to implement the table E_DomainValues describing enumeration types because otherwise their Values allowed would not be configurable.