This section describes the semantics of each table in the knowledge base, and for reference purposes, provides information on each individual table field. Tables represent a convenient tool for decomposing the data into understandable parts, and so we use the knowledge base's table organization to guide us through the discussion of data semantics.
If you edit the knowledge base via the forms, run the provided integrity checks, and correct any errors introduced, the knowledge base will most likely serve your needs. However, you may need a more detailed understanding if you make significant use of the knowledge base, or if you intend to evolve the structure of the knowledge base and/or the CC Toolbox that it supports.
This section is broken up into five subsections, one for each "type"
of table we are presenting. Breaking out the tables into separate groups
should help explain the knowledge base organization as a whole. The relationships
among the tables are also important in understanding the entirety of the semantics
and are also covered below. The following table describes the organization
of this section based on table types.
Table 4-1. Table Types
Table Type |
Contents |
Records associated with a single type of logical knowledge base entity. Specifically, general threats, general policies, detail attacks, detailed policy statements, and objectives. |
|
Links between two entities at different abstraction levels, as well as other information specific to that relationship. |
|
A hierarchy of questions intended to provide an intuitive overview of the knowledge base. |
|
Characteristics and attributes of logical knowledge base entities that the artificial intelligence of the CC ToolBox relies upon. |
|
Logical entities related to CC Classes, Families, Components, and Elements. |
|
Additional explanatory information. Specifically, a table of acronyms and a table to record your Observation Reports. |
To conveniently follow the discussion of this material, do one or
more of the following:
There is one convention that is used throughout all optional fields of all tables: A dollar sign ($) means that the field is blank because no relevant information applies (as opposed to being blank because nobody thought about what the contents should be).
The detailed description of each table field typically ends with a list of one or more hyperlinks, of the form CC Toolbox Usage: Guidance, Content, Rationale. Each link points to a place in Section 5.1 that explains how the CC Toolbox uses that field. The Guidance link points to an explanation of how the field is used as guidance to you in constructing PPs. The PP Content field points to an explanation of how the field is used in the draft PPs generated by the CC Toolbox. The Rationale link points to an explanation of how the field is used in the draft PP’s Rationale sections. The CC Toolbox refers to the draft PPs it produces as PP Reports.
Although the following subsection titles refer only to tables,
the corresponding forms are discussed as well in those cases
where significant aspects of the table semantics are captured
only in the forms.
This section describes the semantics of the simple tables and their associated forms. These tables are "simple" because they each hold data related to well-defined concepts such as threats, policies, or objectives.
The forms for the simple tables may be readily accessed from the Main Menu form. For the most part, these forms just display the contents of their corresponding tables. Consequently, the emphasis in this section is on the tables rather than the forms. However, as explained in Appendix A, the forms for categories and general environment statements do propagate updates into related mapping and attributes tables.
Figure 4-1 depicts the various levels of abstraction for the simple tables. Notice that they are organized into four abstraction levels: Categories are at the top, followed by general environment statements (i.e., General Threats, policy statements, and Assumptions), followed by detailed environment statements, followed by Objectives. Components are not represented by simple tables, but they are included as a fifth level in Figure 4-1 to show how they fit in the overall abstraction hierarchy.
Figure 4-1: Hierarchy of Simple Tables
The following list describes the general use of simple tables within the knowledge base, with reference to similar uses specified by the CC:
A simple table contains some fields that are common to all simple tables and typically contains additional fields as well. The following paragraphs describe the common fields.
Threat categories provide an organizational mechanism for the threat and attack entities listed in the knowledge base. Each threat category is defined on the basis of those threats associated with a single threat-agent type. For instance, all threats that can be executed by "malicious, unauthorized" individuals are organized under the "Hacker" category. The Threat Categories table contains the following fields:
Policy categories provide an organizational mechanism for the policy-related entities listed in the knowledge base. Each policy category is defined on the basis of a particular domain of security policy statements. For instance, all policy statements related to Department of Defense (DOD) policies are organized under the DoD category. Currently, this is the only category used in the knowledge base (other than the universal Root category). However, the Policy Categories table provides an extensible mechanism to support other domains as well. This table contains the following fields:
Assumption categories provide an organizational mechanism for Assumptions listed in the knowledge base. The Assumption categories have been organized into a nontrivial hierarchy several levels deep to facilitate exploration. The Assumption Categories table contains the following fields:
A General Threat provides an encapsulation of a particular threat agent type, an attack type, and an asset-loss type. These semantics are derived from the definition used in the CC [CC Part 1, Annex B.2.4]. General Threats are the abstraction used to represent the concept of threats in the TOE environment as described in the CC.
Because a General Threat is an encapsulation based on types, it can represent more than one specific attack, referred to as a "detailed attack" in the knowledge base's terminology (see Section 4.1.8). For instance, a specific attacker may eavesdrop on data being transmitted over a communications line either by tapping the line or by capturing emanations from the line. These are different Attack methods, but they represent the same General Threat against the asset (i.e., confidentiality of the data). General Threats thus provide a convenient specification and user interface concept with which to contain potentially vast (and growing) numbers of specific Attacks.
The General Threats table contains the following fields:
A General Policy Statement provides a categorization of IT security policy principles (e.g., Accountability). Thus, General Policy Statements provide an organizational mechanism for detailed TOE environmental concerns. The knowledge base expresses these detailed concerns as Detailed Policy Statements (see Section 4.1.9).
The semantics of General Policy Statements are derived from the definition of organizational security policies used in the CC [CC Part 1, Annex B.2.4]. However, often the Detailed Policy Statements (see Section 4.1.9) contain the more relevant details of organizational policies.
Currently, the knowledge base omits an important class of General Policy Statements, namely statements of intent to counter general threats. Listing a threat-countering policy in a PP is somewhat stronger than just listing the threat because such a policy not only identifies the threat but also tells how (and how well) the threat is to be countered. A useful future enhancement to the knowledge base would be to provide links from threats to associated threat-countering policies.
This table contains the following fields:
In the knowledge base, General Assumptions list possible security characteristics of both the TOE and its environment. In the case of Assumptions for the environment, the semantics are derived from the definition of Assumptions used in the CC [CC Part 1, Annex B.2.4], as clarified by the CC Evaluation Methodology board. Specifically, Assumptions in the Environment section of a PP are statements that TOE end users (as opposed to evaluators) must validate in their own environment of use.
Assumptions about intended usage and about physical characteristics of the TOE environment are appropriate for the Environment section of a PP because evaluators have no direct way of assessing their validity. High-level statements about the TOE itself (for example, whether it has a network interface) are more appropriate to the TOE Description section of a PP.
It is possible for a PP author to include Assumptions about TOE security features in the Environment Section of a PP. In this case, the PP is making technical claims about the TOE that are to be evaluated by end users rather than TOE evaluators. Although the CC appears to allow such Assumptions, they do place an increased technical burden on the end user, as the evaluation of Assumptions is beyond the scope of a CC-based evaluation.
A valuable future enhancement to the knowledge base would be to split the Assumptions table into two separate tables, one for Environmental Assumptions and one for TOE Description statements.
The General Assumptions table contains the following fields:
A Detailed Attack provides a specific instance of a General Threat (see Section 4.1.5). For example, a login spoofing attack is an instance of spoofing in general. The major difference is that the attack method for a Detailed Attack is not a type but rather a specific exploit of an explicit vulnerability.
Because of its narrower scope, a Detailed Attack provides a more practical starting point for well reasoned countermeasures that, in the knowledge base, are cast as sets of Security Objectives. Although PPs need not contain detailed Attacks, you do need to perform a security analysis in order to write a useful PP. Similarly, we developers of the knowledge base needed to perform security analyses in order to understand how general threats and policies can be adequately addressed by Security Objectives. We performed this analysis by enumerating detailed Attacks that could be used to mount each General Threat.
This table contains the following fields:
A Detailed Policy Statement provides a specific elaboration of a General Policy Statement (see Section 4.1.6). For example, Audit Generation is a specific elaboration of Accountability. Detailed Policy Statements typically correspond to second-order organizational security policy statements. Although not always the case, Detailed Policy Statements are often closer to the typical level of specification for CC environmental policy statements than General Policy Statements.
This table contains the following fields:
Security Objectives serve three overlapping purposes [cf. CC, Part 1, Section 2.3, Section 4.3.2, and Annex B.2.5]:
To address security concerns expressed in the Environment section of the PP. Specifically, to provide statements of intent to counter identified threats and/or satisfy identified organization security policies and assumptions.
To identify responsibilities for the TOE and for its environment.
Implicitly, to structure the effectiveness analyses in the PP's Requirements Rationale section.
Objectives in the knowledge base directly serve the first and third of these purposes. Objectives provide a natural-language description of a statement of intent regarding some aspect of protection. Through mapping tables, the knowledge base associates detailed Attacks and policies with Objectives that address them (see Section 4.2.7, Section 4.2.8), providing coverage alternatives. In addition, the knowledge base associates Objectives with collections of CC components that may implement them (see Section 4.2.9). Thus, Objectives form a bridge between statements of security need and the Component mechanisms used to provide needed security protection.
There is no preconceived notion within the knowledge base that Objective-specified capabilities will be provided in whole or in part by the TOE, or for that matter, will be provided by information technology (IT) requirements rather than user procedures. However, it is generally the case that some aspect of every Objective in the knowledge base is capable of implementation using IT. This is an artifact the knowledge-base designers' (pragmatic) priorities and should not be taken as intentional bias against non-IT solutions.
A key consideration in designing Security Objectives for the knowledge base was to avoid proliferation of multiple similar objectives. This led to a distinction between two kinds of objectives:
Specific Objectives are directly usable, either alone or in conjunction with other objectives for countering a particular threat or meeting a particular security policy.
Generic Objectives tend to describe generic security services and usually must be specialized before they are directly useful in countering threats or supporting policies. In some cases, a generic objective is closely aligned with a particular CC Family.
Generic objectives counter proliferation through reusability. However, they typically require specialization, a process that is analogous to applying operations to CC components. Specifically, specialization is the process of restating an Objective to make it more specific.
The distinction between generic and specific objectives is noted informally in the Objective Editorial fields of the knowledge base. Some Objectives in the knowledge base explicitly list possible variants and/or implementations, in which case specialization may be performed by merely selecting one of the given variants. (Note, however, that picking a given implementation does not necessarily provide a clear understanding of how the objective has been made more precise.)
In the knowledge base, specialization is supported by the Countermeasure Application and Safeguard Application fields of Detailed Attacks and Policies. These fields allow specialization according to how a given detailed environment statement is to be addressed. As explained below, specialization is supported in the mapping tables from Detailed Attacks to Objectives and from Detailed Policy Statements to Objectives. These lower-level fields have the advantage of more tightly binding the specialization to a particular Objective.
This table contains the following fields:
This section describes the semantics of the Mapping tables and their associated forms. Each mapping table provides links between a pair of adjacent tables in the hierarchy of simple tables depicted in Figure 4-1. Their corresponding forms may be reached via the Links buttons on the Main Menu form.
When two simple tables are linked by a mapping table, the more abstract table is referred to as its source table and the less abstract table as its target table. The two simple tables associated with a mapping table are, in every case, evident from the name of the mapping table. For example, the Attack/Objective Mapping table has Detailed Attacks as its source and Objectives as its target. As explained below, the target may, in some cases, be the union of two different tables, with the union being given by an SQL union query.
In general, a mapping table may define a many-to-many relationship between its source table and its target table. That is, a given source record may map to multiple target records and several different source records may map to the same target record.
The associated form for a mapping table serves primarily to display the table. Mapping tables rely on pop-up lists and are initially locked to prevent accidental editing. In addition, the most abstract mapping tables contain some integrity checks to ensure that categories and environment statements are properly used. The primary emphasis in this section is on the tables themselves rather than their forms.
A couple of the mapping tables used by the CC Toolbox are
actually record sets defined by queries. These queries are
included here at the end of this section for the sake of a simple
exposition.
A mapping table contains some fields that are common to all mapping tables and typically contains additional fields as well. The following paragraphs describe the common fields.
This table maps Threat Categories (see Section 4.1.2) to General Threats (see Section 4.1.5). The table and its associated form allow a threat category to be mapped to either a general threat or to a Threat (sub)Category, but the knowledge base currently does not make significant use of threat subcategories.
This table contains the following fields:
This table maps Policy Categories (see Section 4.1.3) to General Policy Statements (see Section 4.1.6). The table and its associated form allow a Policy Category to be mapped to either a General Policy Statement or to a Policy (sub)Category, but the knowledge base currently does not make any significant use of policy subcategories.
This table contains the following fields:
This table maps Assumption Categories (see Section 4.1.4) to General Assumptions (see Section 4.1.7) and Assumption (sub)Categories. The knowledge base makes significant use of the capability for Assumption subcategories.
This table contains the following fields:
This table maps General Threats (see Section 4.1.5) to Detailed Attacks (see Section 4.1.8). For new data added to the knowledge base, every Detailed Attack should be organized under some General Threat. However, the knowledge base does not currently check for this.
This table contains the following fields:
This table maps General Policy Statements (see Section 4.1.6) to Detailed Policy Statements (see Section 4.1.9). For new data added to the knowledge base, every Detailed Policy Statement should be organized under some General Policy Statement. However, the knowledge base does not currently check for this.
This table contains the following fields:
This table maps Detailed Attacks (see Section 4.1.8) to Objectives (see Section 4.1.10).
In addition to the simple mapping relationship captured in this table, additional fields explain how to specialize an objective in order to help counter an associated Attack. There are also fields to explain how to specialize an objective's implementation (i.e., the realization of safeguards via CC Components), in order to correctly implement a specialized objective.
As explained already in Section 4.1.10, specialization facilitates reuse of the knowledge base's Objectives while simultaneously providing for a more precise response to the PP's environment statements.
This table contains the following fields:
This table maps Detailed Policy Statements (see Section 4.1.9) to Objectives (see Section 4.1.10).
In addition to the simple mapping relationship captured in this table, additional fields explain how to specialize a target objective in order to help support the associated source Detailed Policy, and having done that, how to specialize the Objective's implementation in order to correctly implement the specialized Objective.
As explained already in Section 4.1.10, specialization facilitates reuse of the knowledge base's Objectives while simultaneously providing for a more precise response to the PP's environment statements.
This table contains the following fields:
This table maps Objectives (see Section 4.1.10) to CC Components (see Section 4.5.8) and CC-Extending Components (see Section 4.5.4).
As a result of the overall knowledge base design, components associated with all implementations of a given Objective will appear in this table, without distinction. Guidance about which components to use for a given implementation is provided in the Implementation Application field of the Objectives table (see Section 4.1.10). Therefore, although the table structure itself does not provide a distinction between different implementations of the Objective, the Toolbox does make relevant guidance and distinctions available.
This table contains the following fields:
This query is obtained by composing Threat/Attack Mapping table with the Attack/Objective Mapping table in the obvious way. This query supports the following fields:
This query may be viewed using the Threat/Objective
Mapping form, which is available from the Forms tab on the main MS Access Database window and from several
other forms as well.
This query is obtained by composing General Policy Stmt/Detailed Policy Stmt Mapping table with the Detailed Policy Statement/Objective Mapping table in the obvious way. This query supports the following fields:
This query may be viewed using the General
Policy Stmt/Objective Mapping form, which is available
from the Forms tab on the main
MS Access Database window and
from several other forms as well.
The Prompts form is reached by pressing the Prompts button on the Main Menu form. The prompts are intended to provide an easy overview of the environment statements and categories. Section 4.3.1 below provides an overview of the Prompts form and table. Section 4.3.2 specifies the form and contents of each record field in the Prompts table.
The Prompts form is designed to provide a small window into the hierarchy of prompts questions. The form opens to the RootPrompt at the top of the hierarchy — it is the only prompt with Rank 0.
To view the nodes just below a given node in the hierarchy, select various Prompt IDs from the form's Child List; the statement of the selected Prompt will appear in the box to the right. Pressing the Goto Selected Child button causes the form to move down in the hierarchy to the selected child Prompt. Typically, there is only one way to get to a given child, so that pressing the First Parent button will undo the effect of the Goto Selected Child button.
For each Prompts question, there is an associated list of possible answers and corresponding effects. Selecting an answer automatically selects its associated effect. After this, pressing the Open Selected Effect button will open the appropriate simple-table form for the selected effect.
The Prompts form is initially locked because it displays fields of the Prompts table in a way that does not permit convenient editing. Unlocking the form causes selectable lists to be replaced with editable, comma-separated lists and also hides fields and buttons that are not directly related to the contents of the Prompts table.
Since the Prompts table is highly structured, there are several integrity constraints that should be checked whenever it is edited. These checks are activated by pressing the five integrity-check buttons on the Prompts form. As explained in more detail in Appendix A.4.2, the five integrity checks are:
Prompt Hierarchy Check – The prompts do form a well-defined hierarchy (e.g., no loops).
Has Parent Check – The only prompt without a parent is the RootPrompt.
Answers-Match-Effects Check – Each effect list has the same length as its corresponding answer list.
Child-Link Definition Check – The prompts hierarchy is consistent with the Category mapping tables (e.g., a threat category may not appear below a general threat in the hierarchy).
Child-Link Completeness Check – Every category and general environment statement is referenced somewhere in the Prompts table.
The knowledge base maintains attributes on environment statements to help in their comparison. Attributes are maintained for general environment statements (Threats, Policies, and Assumptions) as well as for Attacks and Detailed Policy Statements. The attributes themselves were originally designed for characterizing Threats and Attacks and were then extended to cover Policies, Assumptions, and Detailed Policy Statements as well.
Section 4.4.1 below explains the
purpose of the form and how to find it. Section 4.4.2 introduces the attributes
used to characterize environment statements. Finally, Section 4.4.3 shows how they might be
used to relate similar environment statements.
The precise name of the Attributes table is TX Env/Attributes. Its corresponding form is TX_Attributes; the form may be reached either through the Attributes button on the Main Menu or by going to the Forms tab on the main database window.
The top two pop-up lists on this form display Attribute key fields. The list marked "Attributes:" tells what kind of environment statement is being characterized. The list marked Record_ID tells which environment statement of the given kind is being characterized. The Show Environment Statement button, just below, will open the appropriate form and display the definition of the environment statement being characterized.
The attributes are based on the CC's understanding of threats [cf. CC, Part 1, Annex B.2.4]. In the case of a Threat (or an Attack), they have to do with the Agents that mount the threat, the Methods used to carry out the threat, and the possible Results, including both affected resources and effects on those resources. In the case of a Policy (or Detailed Policy Statement), the attributes apply to the threat that the policy will not be met. In the case of Assumptions, the attributes apply to the threat that the Assumption will be violated.
All attributes are optional. A null value for an attribute means that the value is unknown. In doing a worst-case threat analysis, such a null value is equivalent to choosing the worst possible case.
There are three kinds of Attribute fields:
Attributes that take on scalar values. These Attributes have singular names and are supported on the Attributes form via pop-up lists. CC Toolbox Usage: Section 5.1.2 - Guidance.
Attributes that represent a set of one or more options. These Attributes have plural names and are also supported via pop-up lists, but the list values are themselves comma-separated lists of one or more elements. These Attributes always contain a maximum value (e.g., Any) abbreviating the list of all possible options. CC Toolbox Usage: Section 5.1.2 - Guidance.
Attributes that are essentially unconstrained. These are supported by simple text boxes. The associated text values must be less than 100 characters in length.
The Attributes form is initially locked to facilitate looking
at possible Attribute values without accidentally making a
selection and thus changing a record.
The fields in the Attributes table serve several different purposes. The following list is grouped into sub-lists according to purpose.
The key fields determine which table the environment statement comes from, as well as the particular record in that table.
Threat Agents are characterized in terms of Agent Types, Authentication, Attitude, Motive, Sophistication, Localities, and Forces. The chosen classification approach was influenced by previous classification efforts due to [Longstaff 97 (access required)], [Perry 84 (perpetrators)], and [Howard 97 (attackers)].
Threat methods are characterized in terms of Lifecycle Phases, Human Roles, Actions performed, and Vulnerabilities and Exposures exploited.
Threat results are characterized in terms of Loss Types, affected IT Capabilities, loss Locations, and affected Security Functions.
The See Also list uses the Attributes of the environment statements to identify related environment statements. This list is based on the assumption that if you are interested in a particular environment statement, then you may also be interested in statements associated less sophisticated agents, more easily applied methods, and similar losses. In more detail, the three comparisons behind the See Also list are as follows:
Less sophisticated: The agent type is a subset of the current agent type, and the agent can operate from fewer localities. If human, the agent has more benign motives and attitude, is less sophisticated, requires less authentication. If non-human, the agent has fewer forces at its disposal.
More easily applied methods: The methods may be applied during fewer lifecycle phases. If the agent is human, the methods may be applied using less sophisticated roles.
Similar results: The results may involve some of the same kinds of losses, affect some of the same IT Capabilities, occur in some of the same locations, and compromise some of the same TSF functions.
One may select any item on the See Also list and learn about its attributes by pressing the associated Go button.
Here is an example of the sort of information one can obtain from the See Also list. The threat User_Send (User abuses authorization to send data) may result in a loss of Confidentiality and/or Integrity. Other threats with similar loss characteristics that are no more difficult to carry out are as follows:
User_Err_Conf (User errors cause confidentiality breaches)
User_Err_Integrity (User errors cause integrity breaches)
User_Err_Slf_Protect (User errors undermine the system's security features)
User_Modify (User abuses authorization to modify data)
Of these, User_Err_Slf_Protect is listed as being more general, in that it can lead to arbitrary kinds of loss. Consequently, this threat has a somewhat larger See Also list.
The algorithm behind the See Also list can only make use
of Attributes that have a well-defined value set.
Consequently, the algorithm ignores the Action Attribute, as well as the Exposures and Vulnerabilities
Attribute. Legitimate machine use of the Attributes table
thus relies on assuring that Attribute values have known
machine-processable meanings. Mechanisms that provide this
assurance are presented in Appendix A;
see especially Appendix A.4.1.
As explained more fully in Appendix A.4.1, most of the Attribute values are required to come from scalar tables whose sole purpose is to restrict the set of possible values for that Attribute. The following table lists these enforcement tables, the Attribute whose value set they define, and the key field that holds the legal values.
Table 4-2. Enforcement Tables for Attribute Values
Attribute |
Enforcement Table/Query |
Key field |
| Agent_Types | TXN_Agent_Types | Agent_Type |
| Attitude | TXN_Attitude | Attitude |
| Authentication | TXN_Authentication | Authentication |
| Env_Aspect | TXN_Env_Aspects | Context_Type |
| Forces | TXN_Forces | Force |
| Human Role | TXN_Human_Role | Human_Role |
| IT Capabilities | TXN_IT_Capabilities | IT_Capabilities |
| Lifecycle Phases | TXN_LifeCycle_Phases | LifeCycle_Phase |
| Localities | TXN_Localities | Locality |
| Locations | TXN_Locations | Location |
| Loss Types | TXN_Loss_Types | Loss Category |
| Motive | TXN_Motive | Motive |
| Sophistication | TXN_Sophistication | Sophistication |
| TSF Functions | All Classes - star (a query) | Class Identifier |
There are two kinds of CC related knowledge base tables, CC-Extending tables and CC-Capture tables. The former support development of new CC components as described in the CC Part 3 Families APE_SRE and ASE_SRE. The later just captures some needed information from Parts 2 and 3 of the CC. This section first presents common information on CC-Extending tables, and then discusses individual table fields, with emphasis on features that are specific to individual forms and tables, including the CC-Capture tables. Queries used to combine CC-Extending tables and CC-Capture tables are included at the end of this section.
The CC-Extending tables and forms may be reached by clicking the Classes, Families, Components, or Elements buttons at the bottom of the Main Menu in the box labeled CC Extensions. They can also be reached directly by going to the Forms tab of the main database window and clicking on CC-Extending Classes, CC-Extending Families, CC-Extending Components, or CC-Extending Elements. In each case, the form manages the content of the corresponding table of the same name.
In contrast to the simple tables described above, the CC-Extending tables do not have associated mapping tables, since at each level, there is just one associated record at the next higher level.
The following paragraphs describe fields that are common to the four CC-Extending tables and their associated forms. In some cases (represented in Italics), the field name varies but has a common form and purpose. In other cases, the same field name (represented in bold) is used in all tables.
The CC does not discuss CC-Extending Classes, but the knowledge base includes them as a matter of convenience to assist in organizing new Families and Components. This table contains the following fields:
The CC does not discuss CC-Extending Families, but the knowledge base includes them as a matter of convenience to assist in organizing new Components. This table contains the following fields:
This table supports the introduction of new Components per requirements given in Part 3 of the CC. It is directly linked to by the Objective/Component Mapping table. This table contains the following fields:
The CC does not require rationale for individual elements of new Components, and there is no Rationale field for this table. If you wish to provide rationale for an individual element, we recommend that you place it in the Rationale field of its parent Component where reviewers are more likely to find it. This table contains the following fields:
This table is used to support queries and Observation Reports. For example, the form for CC-Extending Families uses the CC Classes table to list containing CC Classes and CC-Extending Classes. This table contains the following fields:
This table is used to support queries and Observation Reports. For example, the form for CC-Extending Components uses the CC Families table to list containing CC Families and CC-Extending Families. This table contains the following fields:
This table is included to support queries and Observation Reports. It contains the following fields:
The All Classes query computes a partial union of the CC Classes table and the CC-Extending Classes table. Not all fields could be represented because Access doesn't support memo fields in query Unions. However, the table does provide the following fields:
The All Families query computes a partial union of the CC Families table and the CC-Extending Families table. Not all fields could be represented because Access doesn't support memo fields in query Unions. However, the table does provide the following fields:
The All Components query computes a partial union of the CC-Components table and the CC-Extending Components table. Not all fields could be represented because Access doesn't support memo fields in query Unions. However, the table does provide the following fields:
The knowledge base contains two tables that play a supporting role and have their own unique structure. One is the DKORs table used for making observation reports. The other is the Abbreviations table.
The DKORs table can be reached from virtually every form in the knowledge base via the DKOR button. Pressing the DKOR button automatically opens a new observation report with pre-filled information on the DKOR's author, a locally unique DKOR ID, the current date, and the table and record for which the DKOR is being generated. The DKORs table contains the following fields, which are grouped according to purpose for convenience.
The use of this table is described in detail in Appendix A.5.2. The table has the following fields:
The Abbreviations table is reprinted in full in Appendix B. This table contains the following fields: