WissDB . since Jun 15 . Index . DOCs TOP TOC

WissDB: Data Model & Data Model Semantics

This section describes

C_ WissDB_DM : The WissDB data model from a user’s point of view.

We specify it in ERD Notation (a formal language described in the last chapter of this document). The physical data model is described in section 3 via SQL CREATE TABLE statements.


One important requirement on the data model we need is that it must not require Result instances to have any specific structure. What me mean is: Though we need some structure, this structure should not be more than a WissDB-specific view the user should have not problems to define and to use.

Our solution idea is to have this view present in form of a hierarchical structure that is given by logical locations (unique resource identifiers that are not  simply atomic names but have a structure to let us see how items are nested into each other in the view of WissDB). The domain representing these identifiers is D_ Locator:



-  d              D_ Name                       VARCHAR(80)

                  Values of type D_Name are case-insentive. Each of them

                  must be a string that could be used as a name for a file in

                  Microsoft's NTFS file system.



-  d              D_ Locator                  VARCHAR(255)

                  A value of type D_Locator is a string N/ or x/N/ such that N is a

                  D_Name, and x/ is either empty or again a D_Locator (x could be a 

                  number which is then called a Project Locator Alias).

                  A D_Locator is called a Schema Locator if and only if the

                  last name N in the locator is any of the following:


                  .  Process

                  .  Role

                  .  Result

                  .  Description

                  .  Structure

                  .  Aspect


                  Locators have to be seen as logical URLs (so-called URIs). The

                  WissDB server is to map them to concrete URLs (resp. onto resources

                  that are to be protected by access permissions). 


                  As we will learn in the following, Instance Locators do always     

                  start with a corresponding schema locator.


                  Example: This document here has for its instance locator the

                  URI WissDB/Result/WissDB/Design/Data Model Specification (the last slash

                  in locators is seen only in the view of the DBMS).



It is important to note that WissDB is managing, first of all, meta data representing information about knowledge items. To store knowledge items itself, WissDB may rely on one or more other systems.


Before we now start to design entity types, let us define all domain types needed. Please note that that the boxes Item Type and Description Type shown in the picture above collapse into only one domain type D_ItemType: The Description of a Result will from now on be seen as being a specific part of the Result. It should be given a locator matching the pattern


D_Locator / Result / Result Name / Description.


Example: If in the WissDB Project we had a document specifying what the outcome of the design phase should be, this paper’s URI would be WissDB/Result/Design/Description.

Note: WissDB/Result/Design is to be understood as a result type (not as an activity). An activitity may have results of different types.


In addition to D_Locator, subsystem WissDB of WissDB defines the following domain types:

-  d              D_ ItemType                   INT


                  Valid values are:

-  v              .  Description of Process

-  v              .  Description of Role

-  v              .  Description of Result

-  v              .  Description of Practice Candidate

-  v              .  Practice Candidate (a zipped Knowledge Package)

-  v              .  Solution Requirement

-  v              .  Solution Concept

-  v              .  Solution Code

-  v              .  Business

-  v              .  Technology

-  v              .  Advice

-  v              .  Information


                  Please note: In this and also all the following domain types

                  the set of valid values should be capable of being redefined

                  when need arises. So, what we show in this document, is more

                  or less a suggestion only.


                  To give an example: In the picture on page 3 there is a value

                  Solution mentioned. In the design here we have split it up into

                  three more specific values (Solution Requirement, Solution Design,

                  and Solution Code).


                  To implement WissDB in a way guaranteeing such flexibility should be

                  seen as an important requirement.



-  d              D_ PracticeType             INT


                  Valid values are:

-  v              .  Best Practice

-  v              .  Lesson Learned



-  d              D_ ViewType                   INT

                  Valid values are:

-  v              .  Concept

-  v              .  Implementation



-  d              D_ AbstractionType        INT


                  Valid values are:

-  v              .  Solution

-  v              .  Template

-  v              .  Pattern

-  v              .  Strategy



-  d              D_ UsageType                INT

                  Valid values are:

-  v              .  Sample

-  v              .  Reference

-  v              .  Use after customization

-  v              .  Use as is



-  d              D_ CorrelationType       INT

                  Valid values are at least:

-  v              .  B is Solution Concept for Requirement A

-  v              .  B is Code implementing Concept A

-  v              .  B is Solution Concept based on Technology A

                  During the lifetime of WissDB many more such values might

                  be added.



In order to ensure that the set of valid values for enumeration domain types can be recon-figured (or at least extended), we implement an auxiliary table documenting these values:


-  ec             E_ DomainValues


-  eca,pk         A_DomName                     D_DomainName

-  eca,pk         A_DomValue                    D_ValueName

-  eca,nn         A_ValueAsNr                   D_ValueNumber

-  eca            A_Semantics                   D_Comment

-  eca            A_ObsoleteSince               D_Date



Having defined all domain types needed, we are now ready to define the WissDB entity types:

There are four core entity types in WissDB. They model Processes, Activities, Roles, and Knowledge Items:


-  ec             E_ Process



-  eca,pk         A_Loc                         D_Locator

-  eca,nn         A_Description                 E_KnowledgeItem

-  eca            A_Role                        E_Role


                  Each process locator is to match the pattern

                  D_Locator/Process/Process_Locator (where the Process_Locator

                  may contain slashes: A process is seen as an activity that is

                  broken down hierarchically in subprocesses which, depending

                  on the concrete contex, you may see as processes, phases or

                  simple atomic tasks).



-  ec             E_ Role


-  eca,pk         A_Loc                         D_Locator

-  eca,nn         A_Description                 E_KnowledgeItem



-  ec             E_ KnowledgeItem


-  eca,pk         A_Loc                         D_Locator

-  eca,nn         A_Type                        D_ItemType

-  eca            A_NodeValue                   D_NodeValue


                  Containment of Knowledge Items is reflected via the D_Locator

                  values in A_Loc (which are the knowledge items’ URIs).



Type E_KnowledgeItem has specializations. They model Practice Candidates, Results and (accepted) Practices. Furthermore we have, on the set of all knowledge items, a generic relation R_Is_related_to. It is to allow us to model binary item associations of different semantics:



-  ec             E_ Candidate


-  eca,pk         A_                           e_KnowledgeItem

-  eca,nn         A_from                        D_EMailAddress



-  ec             E_ Result


-  eca,pk         A_                           e_KnowledgeItem

-  eca,nn         A_View                        D_ViewType

-  eca,nn         A_Abstraction                 D_AbstractionType

-  eca,nn         A_Usage                       D_UsageType

-  eca            A_isResultOf                  E_Process


                  Valid values of type E_Result.A_Loc need to match the

                  pattern D_Locator/ Result/D_Name.


                  All items that are seen as part of such a Result have to have

                  a locator being prefixed by the Result’s locator.



-  ec             R_ Is_related_to


-  eca,pk         A_A                           E_KnowledgeItem

-  eca,pk         A_B                           E_KnowledgeItem

-  eca,pk         A_Correlation                 D_CorrelationType



This model implies that each result may be a hierarchy of smaller knowledge items. The nesting is given via the item locators. Furthermore – because of the generic relation R_Is_related_to – a result can also have correlation structure.



-  ec             E_ Practice


-  eca,pk         A_                           e_Result

-  eca            A_PracticeType                D_PracticeType

-  eca            A_reuse_0                     D_Counter

-  eca            A_reuse_1                     D_Counter

-  eca            A_reuse_2                     D_Counter

-  eca            A_reuse_3                     D_Counter



                  A_reuse_0 = number of downloads

                  A_reuse_1 = number of ratings "reuse value minimal"

                  A_reuse_2 = number of ratings "reuse value moderate"

                  A_reuse_3 = number of ratings "reuse value quite high"



We see: Specific results can be marked to be either Best Practice, or Lesson Learned.

Users who downloaded such a Practice instance could some time afterwards receive an e-mail asking them for a rating. The data model allows to maintain such rating results.

Note also: If a result is a practice instance, it may loose this quality later on (because it is always possible that better practices are found, or simply because technology changes to the effect that previous best practice solutions are no longer acceptable).


Given the fact that only Results can be Practice items, two questions could be asked:


–      Could it be useful also to support the classification of any item as Best Practice or Lesson Learned?

–      Could it be useful to support practice instances that are a set of results?


The current design does not support practice instances to be a sequence of results that are not nested into each other

–      because that would complicate the model,

–      because practice instances should not get too large anyway (the smaller a practice instance is the greater the chance that it will be reused), and

–      because via their locators you always could give results a hierarchical structure: a structure nesting results into more complex results.

There could, e.g. be a result

The WissDB System

and nested therein

The WissDB System/ Result/ The WissDB System.

You should also note that the data model proposed here does not force us to assign, to a given result, a specific process – we are only allowed to do so.

Though we do not support classifying each item as Best Practice or Lesson Learned, the user will always be able to do so by choosing a Locator that makes that item a result.

So you see: A Result is a knowledge item we can associate with an Process (i.e. a named activity). Having done so, the result may also be associated with a Role.  We can – but need not – make it a Practice Instance.

Results should always be well documented, and so there could e.g. be a convention saying that each Result is to have a Description (our data model does not enforce this per se, but item locators will always show you whether there is such documentation: Items that are result descriptions are to have a locator matching the pattern

D_Locator/ Result/ NameOfResult/ Description 



The last part of the WissDB data model is to support the indexing of knowledge items:



-  ec             R_ Is_keyword_for


-  eca,pk         A_keyword                     E_Aspect

-  eca,pk         A_for                         E_KnowledgeItem



-  ec             E_ Aspect


-  eca,pk         A_Loc                         D_Locator


                  If X/Y is an E_Aspect.A_Loc, then X is said to be a

                  Knowledge Area for which Aspect Y makes sense.


                  Examples could be:


                      X = Software/Implementation

                      Y = Technology


                      X = Project Management

                      Y = Risk Management/Checklist



The rationale for this modeling is: If a user is indexing an item by associating keywords to it, he should be asked to do so by first selecting a knowledge area and then, in a second step, one or more existing aspects (which again could be knowledge areas).

To have such a structure on the set of all keywords allowed will help us to restrict any search for result items to quite specific knowledge areas.


Finally we have means to associate processes and results to concrete projects. This however is an additional view applications may or may not have use for:



-  d              D_ ProjectLocator   Positive Integer

-  ec             E_ Alias


-  eca,pk         A_Nr                          D_ProjectLocator

-  eca            A_Loc                         D_Locator


                  Values of type E_Alias.A_Loc are not allowed to contain one of

                  the reserved names Aspect, Process, Role, Result, Description, Structure,

                  or Selector. They may however start with a D_ProjectLocator


How to work with Aspects

Knowledge Packages

WissDB . Index . DOCs . TOC