TOP TOC 
WissDB . since Jun 15 . Index . DOCs TOP TOC
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.
Pre-considerations
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:
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.
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:
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.
Valid values are:
- v . Best Practice
- v . Lesson Learned
Valid values are:
- v . Concept
- v . Implementation
Valid values are:
- v . Solution
- v . Template
- v . Pattern
- v . Strategy
Valid values are:
- v . Sample
- v . Reference
- v . Use after customization
- v . Use as is
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:
- eca,pk A_DomName D_DomainName
- eca,pk A_DomValue D_ValueName
- eca,nn A_ValueAsNr D_ValueNumber
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:
|
- 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).
|
- eca,pk A_Loc D_Locator
- eca,nn A_Description E_KnowledgeItem
|
- eca,pk A_Loc D_Locator
- eca,nn A_Type D_ItemType
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:
|
- eca,pk A_ e_KnowledgeItem
- eca,nn A_from D_EMailAddress
|
- 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.
- 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.
|
- eca,pk A_ e_Result
- eca A_PracticeType D_PracticeType
Semantics:
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:
|
- eca,pk A_keyword E_Aspect
- eca,pk A_for E_KnowledgeItem
|
- 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
or
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
|
- 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
| | | |