Designers should focus on the creative aspect of modeling and not spend time on consistency issues. Open ModelSphere provides an assisted technology to ensure the consistency of a model.
The Verify Integrity feature checks your model and produces a report. This report informs you of consistency errors that may have occurred. Furthermore, it provides you with links towards the different objects in the explorer window and the various properties windows. Finally, it lets you apply modifications directly, providing you with a list of possible solutions.
Verify integrity is provided for process,data, domain, common item models as well as for operation libraries.
The
section Rules for verifying integrity
below details the applicable rules and possible solutions.
To use the Verify Integrity feature:
You
can make the changes from the Verify integrity window; use the provided
links (Click to change value to NOT NULL). You can also make the changes
from the Properties window; use the link .
For
the purpose of the present example, errors were added to the model. If
you followed the steps in the Building a data model section, your model
should not have errors.
Rules
for verifying integrity
Conceptual data model
- Change the attribute to NOT NULL
3. An entity should have an attribute (warning).
4. An attribute should have a relationship (warning).
5. An entity must have a primary key or a unique key.
6. The multiplicity of a role must be defined.
7. A relationship must not have an arc with a dependency if its dimension is greater than two.
8. A relationship must not have more than one arc with a dependency.
9. A relationship must have at least two arcs.
10. A relationship must not have an arc with a dependency if it is recursive.
11. A relationship should not have an attribute if it has at least one role with a multiplicity "exactly 1"
(warning).
12. An arc with a dependency must have a role with multiplicity "exactly 1".
13. A binary relationship must have exactly one navigable role, and this role's multiplicity is not greater than the
other role's multiplicity (warning).
14. In a binary relationship, if an arc has a dependency which is not the only part of the key, the other arc
must have a role with a multiplicity greater than 1.
Relational data model
- Change the column to NOT NULL
2. For a minimal connectivity of 1, corresponding foreign key columns should be NOT NULL:
- Change the column to NOT NULL
- Change the role multiplicity from ‘exactly one’
to ‘optional or from ‘one or more’ to’ many’
3. For a minimal connectivity of 0, corresponding foreign key columns should be NULL:
- Change the column to NULL
- Change the role’s multiplicity from ‘optional’ to
‘exactly one’ or from ‘many’ to ‘one or more’
4. For a parent maximal connectivity of 1, corresponding foreign key columns in the
child table should be part of a unique constraint or a unique index:
- Change the parent role’s multiplicity from ‘exactly one’
to ‘one or more’ or from ‘optional’ to ‘many’
- Add the unique index or modify existing FK’s index to a unique value
5. For a parent maximal connectivity of N, corresponding foreign key columns in the
child table should not be part of a unique constraint or a unique index:
- Change the parent role’s multiplicity from ‘one or more’
to ‘exactly one’ or from ‘many’ to ‘optional’
- Modify existing FK’s index to a non unique value
7. A foreign key must apply to a column.
8. The foreign key's domain, length and decimal digits
must match that of the source column (warning).
9. An index must have at least one indexed element.
10. A trigger must have a body defined as well as a column
linked (warning)
11. At most one role for a given association can have
a multiplicity greater than 1 (warning).
12. An update rule for a given role must be defined (warning).
13. The multiplicity for a given role must be defined.
Domain model
Operation
library
2. A parameter must have a type.
2. A process should have a graphical representation(warning).
3. A process should not be linked directly by a flow to another process (warning).
4. A process should not be an orphan without input or output flows (warning).
5. A process should have at least one input flow (warning).
6. A process should have at least one output flow (warning).
7. A process should have a name other than the default name (warning).
8. An external entity should have a graphical representation (warning).
9. An external entity should not be an orphan without input or output flows (warning).
10. An external entity should not be linked directly by a flow to another external entity (warning).
11. An external entity should have a name other than the default name (warning).
12. An external entity should have at least one input flow (warning).
13. An external entity should have at least one output flow (warning).
14. A store should have a name other than the default name (warning).
15. A store should have a graphical representation (warning).
16. A store should not be linked directly by a flow to another store (warning).
17. A store should not be linked directly by a flow to an external entity (warning).
18. A store should not be an orphan without input or output flows (warning).
19. A store entity should have at least one input flow (warning).
20. A store entity should have at least one output flow (warning).
21. A flow should have an emission condition (warning).
22. A flow should have a name other than the default name (warning).
23. A flow should be linked at both extremities (warning).
Common
items model