Difference between revisions of "Modeler:Tutorial/Integrity Checks"
m |
|||
| Line 1: | Line 1: | ||
= Every fact type must have an intra UC = | = Standard FCO-IM rules = | ||
The following rules are present since the very first version of CaseTalk and are a hardcoded set of rules. | |||
== Every fact type must have an intra UC == | |||
For each fact type, there must be at least one uniqueness constraint that concerns one or more roles of this fact type only. | For each fact type, there must be at least one uniqueness constraint that concerns one or more roles of this fact type only. | ||
= The N rule must be valid for every nominalized fact type = | == The N rule must be valid for every nominalized fact type == | ||
Every nominalized fact type with n roles only has exactly one uniqueness constraint over all n roles. Generalizations are an exception, therefor this is considered a warning, not an error. | Every nominalized fact type with n roles only has exactly one uniqueness constraint over all n roles. Generalizations are an exception, therefor this is considered a warning, not an error. | ||
= The N-1 rule must be valid for every fact type = | == The N-1 rule must be valid for every fact type == | ||
Facts are required to have one or more uniqueness constraint over N-1 roles. The uniqueness constraint should cover all roles, or all roles minus one. If a fact type with n roles has at least one uniqueness constraint on less than n-1 roles, then the fact type is splittable. The n-1 rule-test simply consists of the check that there are no UCs that are too small. | Facts are required to have one or more uniqueness constraint over N-1 roles. The uniqueness constraint should cover all roles, or all roles minus one. If a fact type with n roles has at least one uniqueness constraint on less than n-1 roles, then the fact type is splittable. The n-1 rule-test simply consists of the check that there are no UCs that are too small. | ||
In a fact type that is a subtype, all roles have a single role uniqueness constraint. For nominalized subtypes, all object type expressions concern exactly one role. | In a fact type that is a subtype, all roles have a single role uniqueness constraint. For nominalized subtypes, all object type expressions concern exactly one role. | ||
=The alias of an object/fact type must be unique= | ==The alias of an object/fact type must be unique== | ||
Object / fact types names must be unique throughout the model. This list of names includes the alias set at the fact property dialog. | Object / fact types names must be unique throughout the model. This list of names includes the alias set at the fact property dialog. | ||
= All object type expressions must be used = | == All object type expressions must be used == | ||
Object types expressions generally are created during qualification of fact expressions. This rule states that the object type expressions should be verbalized as part of another object types or fact type expression. | Object types expressions generally are created during qualification of fact expressions. This rule states that the object type expressions should be verbalized as part of another object types or fact type expression. | ||
= Non-lexical object types without totality constraints must have a fact type expression = | == Non-lexical object types without totality constraints must have a fact type expression == | ||
If no totality constraint at all applies to any of the roles played by a certain nominalized fact type, then that fact type must have an existence postulating fact type expression. | If no totality constraint at all applies to any of the roles played by a certain nominalized fact type, then that fact type must have an existence postulating fact type expression. | ||
=The actual population of every fact type must be verbalizable= | ==The actual population of every fact type must be verbalizable== | ||
Object type expressions verbalizing a population is not always sufficient to be verbalizable. Sometimes an additional fact type expression or totality constraint is required to guarantee the population really exists. | Object type expressions verbalizing a population is not always sufficient to be verbalizable. Sometimes an additional fact type expression or totality constraint is required to guarantee the population really exists. | ||
=A strict equality constraint must apply on each subtype tupel= | ==A strict equality constraint must apply on each subtype tupel== | ||
The population under a subtype must correspond to the population of the supertype. | The population under a subtype must correspond to the population of the supertype. | ||
= Fact types may not contain redundant role combinations = | = Extended Rules = | ||
The following rules were added after CaseTalk was used for a while, and kept evolving to catch mistakes made by beginners and experienced modelers. | |||
==Roles must have distinct semantic meanings== | |||
More than one role can exist in a fact type. Of more than one role in a fact type are played by the same object type, the modeler should either place a role-fix or insert an extra object type. Transformations will fail if this is not handled. (Consider a table after transformation with two columns having the same name.) | |||
==Label types must contain a datatype definition== | |||
Label types require some data type definition. CaseTalk is able to derive that from the population using a wizard. If not set yet, these label types trigger this warning rule. | |||
= SQL Based = | |||
Once the internal data management got extended with a sql interface, a new set of rules was added using the internal engine's SQL. | |||
== Fact types may not contain redundant role combinations == | |||
Different fact types may contain sets of roles which have a similar construction. The set of roles and their played by object types may be modeled redundant. If so, it can be resolved by combining these role sets into an object type. | Different fact types may contain sets of roles which have a similar construction. The set of roles and their played by object types may be modeled redundant. If so, it can be resolved by combining these role sets into an object type. | ||
=The population should match the value constraints= | ==The population should match the value constraints== | ||
The values in the population should comply to the value constraints as specified in the relevant label types. | The values in the population should comply to the value constraints as specified in the relevant label types. | ||
=The population should match the totality constraints= | ==The population should match the totality constraints== | ||
If a totality constraint states the population must exist in a different fact type, the example population in the model should comply. | If a totality constraint states the population must exist in a different fact type, the example population in the model should comply. | ||
=Facts must have at least one sample population= | ==Facts must have at least one sample population== | ||
Fact types only exist by expressions and samples. Having no tuples makes validating the expression impossible. Therefor at least one sample must exist. | Fact types only exist by expressions and samples. Having no tuples makes validating the expression impossible. Therefor at least one sample must exist. | ||
= | == Fact types may not contain object types == | ||
= Fact types may not contain object types = | |||
Fact types with n roles, and n > 2, with a single UC covering N-1 roles, these roles under the UC may be candidate for nominalization. | Fact types with n roles, and n > 2, with a single UC covering N-1 roles, these roles under the UC may be candidate for nominalization. | ||
= Binary fact types must have grouping preference = | == Binary fact types must have grouping preference == | ||
Binary fact types where both roles are under a single uc, or both roles under their own uc, this fact type cannot be automatically grouped during transformation. Therefor to be optimized, at least one role needs a grouping preference. | Binary fact types where both roles are under a single uc, or both roles under their own uc, this fact type cannot be automatically grouped during transformation. Therefor to be optimized, at least one role needs a grouping preference. | ||
= All generated expressions require validated semantics = | == All generated expressions require validated semantics == | ||
In later version of CaseTalk more model (re)factoring functions exist. This may lead to default generated expressions, which are not manually entered by an analyst. To guarantee model quality, these need to be manually verified. | In later version of CaseTalk more model (re)factoring functions exist. This may lead to default generated expressions, which are not manually entered by an analyst. To guarantee model quality, these need to be manually verified. | ||
= Label types must be used = | == Label types must be used == | ||
Label types can only exist if played by at least one role. Label types found in the model without any role played by this label type, the label type should be removed. | Label types can only exist if played by at least one role. Label types found in the model without any role played by this label type, the label type should be removed. | ||
=Populations must comply with uniqueness constraints= | ==Populations must comply with uniqueness constraints== | ||
The example population should adhere to the uniqueness constraints applied to the corresponding roles. | The example population should adhere to the uniqueness constraints applied to the corresponding roles. | ||
= Populations must comply with totality constraints = | == Populations must comply with totality constraints == | ||
If a tc mandates tuple existence, the population should comply to that. More tuples are required to satisfy this rule. | If a tc mandates tuple existence, the population should comply to that. More tuples are required to satisfy this rule. | ||
= Population must comply with subset constraints = | == Population must comply with subset constraints == | ||
Subset constraints mandate existence of a population in another fact type. Therefor this rule checks if that is the case within the model and the example population. | Subset constraints mandate existence of a population in another fact type. Therefor this rule checks if that is the case within the model and the example population. | ||
= Population must comply with datatype = | == Population must comply with datatype == | ||
Population values are set to be of a specific data type as specified in the corresponding label type. The values are parsed by CaseTalk to validate they meet the datatype requirements. | Population values are set to be of a specific data type as specified in the corresponding label type. The values are parsed by CaseTalk to validate they meet the datatype requirements. | ||
= External expressions must be supported = | == External expressions must be supported == | ||
It is possible to merge fact expressions from another model file (aka namespace) into another. The expressions are flagged as originating from a different namespace. CaseTalk allows architects to specify which namespaces can be used and which not. This rule simple checks for expressions which were not yet marked as valid merged namespace. | It is possible to merge fact expressions from another model file (aka namespace) into another. The expressions are flagged as originating from a different namespace. CaseTalk allows architects to specify which namespaces can be used and which not. This rule simple checks for expressions which were not yet marked as valid merged namespace. | ||
= External namespace must cover one version = | == External namespace must cover one version == | ||
In elaborate editions of CaseTalk various namespaces and versions of them are allowed to be merged into other models. It should however never occur to merge expressions from two distinct versions of the same namespace. | In elaborate editions of CaseTalk various namespaces and versions of them are allowed to be merged into other models. It should however never occur to merge expressions from two distinct versions of the same namespace. | ||
= Value constraints must comply with datatype = | == Value constraints must comply with datatype == | ||
The population contains values and value constraints limits the range of these values. Therefor the limits specified must comply to these datatype themselves. | The population contains values and value constraints limits the range of these values. Therefor the limits specified must comply to these datatype themselves. | ||
=Expression requires soft semantics= | ==Expression requires soft semantics== | ||
Expressions consist of roles and expression parts. If all expression parts in an expression are empty, this warning states the lack of so called soft semantics. | Expressions consist of roles and expression parts. If all expression parts in an expression are empty, this warning states the lack of so called soft semantics. | ||
= | = Custom SQL = | ||
Users are now able to build their own additional set of rules using SQL. | |||
There may be more validation rules active within to your environment. These may have been added by customizations. See also: [[Custom_SQL_Rules|Customization through own rules in SQL]] | There may be more validation rules active within to your environment. These may have been added by customizations. See also: [[Custom_SQL_Rules|Customization through own rules in SQL]] | ||
Revision as of 08:52, 28 August 2018
Standard FCO-IM rules
The following rules are present since the very first version of CaseTalk and are a hardcoded set of rules.
Every fact type must have an intra UC
For each fact type, there must be at least one uniqueness constraint that concerns one or more roles of this fact type only.
The N rule must be valid for every nominalized fact type
Every nominalized fact type with n roles only has exactly one uniqueness constraint over all n roles. Generalizations are an exception, therefor this is considered a warning, not an error.
The N-1 rule must be valid for every fact type
Facts are required to have one or more uniqueness constraint over N-1 roles. The uniqueness constraint should cover all roles, or all roles minus one. If a fact type with n roles has at least one uniqueness constraint on less than n-1 roles, then the fact type is splittable. The n-1 rule-test simply consists of the check that there are no UCs that are too small.
In a fact type that is a subtype, all roles have a single role uniqueness constraint. For nominalized subtypes, all object type expressions concern exactly one role.
The alias of an object/fact type must be unique
Object / fact types names must be unique throughout the model. This list of names includes the alias set at the fact property dialog.
All object type expressions must be used
Object types expressions generally are created during qualification of fact expressions. This rule states that the object type expressions should be verbalized as part of another object types or fact type expression.
Non-lexical object types without totality constraints must have a fact type expression
If no totality constraint at all applies to any of the roles played by a certain nominalized fact type, then that fact type must have an existence postulating fact type expression.
The actual population of every fact type must be verbalizable
Object type expressions verbalizing a population is not always sufficient to be verbalizable. Sometimes an additional fact type expression or totality constraint is required to guarantee the population really exists.
A strict equality constraint must apply on each subtype tupel
The population under a subtype must correspond to the population of the supertype.
Extended Rules
The following rules were added after CaseTalk was used for a while, and kept evolving to catch mistakes made by beginners and experienced modelers.
Roles must have distinct semantic meanings
More than one role can exist in a fact type. Of more than one role in a fact type are played by the same object type, the modeler should either place a role-fix or insert an extra object type. Transformations will fail if this is not handled. (Consider a table after transformation with two columns having the same name.)
Label types must contain a datatype definition
Label types require some data type definition. CaseTalk is able to derive that from the population using a wizard. If not set yet, these label types trigger this warning rule.
SQL Based
Once the internal data management got extended with a sql interface, a new set of rules was added using the internal engine's SQL.
Fact types may not contain redundant role combinations
Different fact types may contain sets of roles which have a similar construction. The set of roles and their played by object types may be modeled redundant. If so, it can be resolved by combining these role sets into an object type.
The population should match the value constraints
The values in the population should comply to the value constraints as specified in the relevant label types.
The population should match the totality constraints
If a totality constraint states the population must exist in a different fact type, the example population in the model should comply.
Facts must have at least one sample population
Fact types only exist by expressions and samples. Having no tuples makes validating the expression impossible. Therefor at least one sample must exist.
Fact types may not contain object types
Fact types with n roles, and n > 2, with a single UC covering N-1 roles, these roles under the UC may be candidate for nominalization.
Binary fact types must have grouping preference
Binary fact types where both roles are under a single uc, or both roles under their own uc, this fact type cannot be automatically grouped during transformation. Therefor to be optimized, at least one role needs a grouping preference.
All generated expressions require validated semantics
In later version of CaseTalk more model (re)factoring functions exist. This may lead to default generated expressions, which are not manually entered by an analyst. To guarantee model quality, these need to be manually verified.
Label types must be used
Label types can only exist if played by at least one role. Label types found in the model without any role played by this label type, the label type should be removed.
Populations must comply with uniqueness constraints
The example population should adhere to the uniqueness constraints applied to the corresponding roles.
Populations must comply with totality constraints
If a tc mandates tuple existence, the population should comply to that. More tuples are required to satisfy this rule.
Population must comply with subset constraints
Subset constraints mandate existence of a population in another fact type. Therefor this rule checks if that is the case within the model and the example population.
Population must comply with datatype
Population values are set to be of a specific data type as specified in the corresponding label type. The values are parsed by CaseTalk to validate they meet the datatype requirements.
External expressions must be supported
It is possible to merge fact expressions from another model file (aka namespace) into another. The expressions are flagged as originating from a different namespace. CaseTalk allows architects to specify which namespaces can be used and which not. This rule simple checks for expressions which were not yet marked as valid merged namespace.
External namespace must cover one version
In elaborate editions of CaseTalk various namespaces and versions of them are allowed to be merged into other models. It should however never occur to merge expressions from two distinct versions of the same namespace.
Value constraints must comply with datatype
The population contains values and value constraints limits the range of these values. Therefor the limits specified must comply to these datatype themselves.
Expression requires soft semantics
Expressions consist of roles and expression parts. If all expression parts in an expression are empty, this warning states the lack of so called soft semantics.
Custom SQL
Users are now able to build their own additional set of rules using SQL.
There may be more validation rules active within to your environment. These may have been added by customizations. See also: Customization through own rules in SQL