The system data model is a key factor in the ease of use, performance and usability of the system. The fact that the SmarTeam system has a flexible data model is a huge advantage, but this advantage should be used correctly, taking into consideration how the CATIA Integration is affected. This page deals with the definition of classes. For information about attributes, see Defining Attributes. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Number of ClassesA CATIA class represents data of CATIA documents in SmarTeam database. The following table describes the CATIA component types treated by SmarTeam - CATIA Integration:
We recommend to avoid a large number of classes, as it affects general performance and from the point of view of usability and understanding by the user, the interface may become too complicated. In the case of a specific data model for a customer, use only the classes that the user needs and remove unused classes in SmDemo (in case this database is used as a starting point for the implementation). |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Recommendation
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Defining Composition RulesThe SmarTeam Data Model Designer allows you to define composition rules. It is recommended to allow only the relevant compositions as this has direct effect on performance. The following table displays the recommended composition for CATIA classes. For component types that do not appear in the table, do not set any composition.
How to define compositionIn the Data Model Designer, define the link classes, their attributes and class composition. To do this, proceed as follows:
Defining Classes as Desktop ObjectsWhen defining classes in the Data Model Designer, you may allow/not allow associating objects of this type with the project desktop by setting the Add as Top Level flag. Assigning a Class to be top level has performance implications due to the special actions executed by SmarTeam during a lifecycle. When Out of Vault operations (Check Out, New Release) are performed on objects of classes that may be desktop objects, the system checks whether the particular object is a desktop object and re-link the newly-created version to the root of the projects to which it was previously linked. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
RecommendationDecide which classes should be allowed on the desktop and define only these classes as desktop objects. Try to minimize the number of classes allowed to be desktop objects. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
How to allow a class to be a desktop object
Standard PartsStandard parts are widely used by designers. The major advantage of using standard parts in CATIA is the reusability of the parts and the time it saves. It is critical that parts that fall into the category of standard parts do not change often, and will be correctly managed and controlled as they may affect almost all your designs For more details, see the Standard Parts Library Methodology Guide. See also Managing Catalogs. STANDARD PARTS REVISION MANAGEMENT The following table provides a brief summary of the advantages and disadvantages of revision management of standard parts.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
RecommendationAlthough there are advantages and disadvantages to each approach, the most effective way to handle standard parts is in a revision-managed fashion even if no new revisions are generated for the standard part. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Assigning a Dedicated Class for Standard PartsThe SmarTeam administrator can assign either standard part class or distinguished standard parts by attributes. The following table summarize of advantages and disadvantages of both methods.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
RecommendationCurrently, it is recommended to use the standard parts class to be able to define lifecycle rules for standard parts. File Control MechanismIn some cases, objects in certain classes are not file-managed, for example, folders in the documents tree. Removing the file control mechanism from a superclass and assigning file control to relevant classes only may have serious performance implications. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
RecommendationTo ensure good performance for the CATIA integration, it is highly recommended that file management is defined at the super-class level. This should also be done for classes in your Documents super class, that do not manage any files. (These classes will not have any file attributes filled and the attributes will not be shown on the profile card). |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
How to define the File control mechanism
Working with Sheets and Internal ComponentsThe SmarTeam - CATIA integration allows the creating of distinct objects for internal components in CATIA Product, and sheets in CATIA Drawing. In some cases, sheets and internal documents do not need to be managed separately. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
RecommendationUnless there is a specific need to manage internal components and/or drawing sheets as distinct objects, it is recommended to disable creating objects. How to disable creating objects for internal components and drawing sheets
|