The UML specification prescribes both a diagram notation and a metamodel. The notation is comparati-
vely complete, capable to document the structural and behavioural characteristics of problem domain and software. However, modelling persistent storage struc-tures has not been the strong point of UML. The UML notation neglects constructs useful for precise analy-sis, design, development and management of relatio-nal schemata. Data modelling-specific notations and techniques have generally been stronger at this task than those oriented around UML. The UML meta-model, however, provides a structure that accommo-dates semantic information beyond what is typically expressed in the UML notation. UML extension mechanisms (profiles) based on stereotypes, tagged values and constraints provide a basis for expansion of its applicability. Types of integrity constraints estab-lished in 0 could be accurately expressed in terms of the UML metamodel and its extensions.
2. Classification of integrity constraints
Integrity constraints categorized according to seve-ral criteria were suggested in 0. By constrained ele-ment, the integrity constraints were divided into 2 groups: integrity constraints on attribute and groups of attributes (Figure 1) and integrity constraints on rela-tionship and groups of relationships (Figure 2).
The fundamental constraints on attribute or at-tribute groups like primary identifier, mandatory, uniqueness constraints are used in all the most popular conceptual modelling methods and implemented in DBVS. The possibility to use constraints on relation-ships depends on what types of relationships are considered in particular method. For relationships, on-ly multiplicity constraints are common to all methods.
Figure 1. Integrity constraints on attributes
Figure 2. Integrity constraints on attributes and relationship
Abstract. Integrity constraints are incident part of conceptual models, including part of semantics of problem domain. Analysis of the most important methods of conceptual modelling has revealed that none of them analyze the complete set of integrity const
Representation of Integrity Constraints in Conceptual Models
Figure 3. Integrity constraints on sets of objects
By scope for which the constraint is applied integ-rity constraints where categorized into constraints on single object, constraints on a set of objects, const-raints on sets of objects and constraints on sequences of sets of different types of objects. A constraint on sets of objects (Figure 3) consists of set comparison constraints that restrict the way the population of one set of objects compares with that of another com-patible set of objects. There are several kinds of set compatible (subset, exclusion, equal set, disjunctive mandatory) constraints that will be defined and ana-lyzed in the following sections.
Looking from perspective of visual modelling of constraints, the ORM 0 – 0 model is quite powerful but also it is rather complex and suitable only to analysis phase. Despite there are methods and capabi-lities to transform ORM models to (and from) envi-ronments of Analysis&Design phase CASE tools (for example, Microsoft Visio-Based Database Modelling in Visual Studio .NET Enterprise Architect), it is difficult to imagine that ORM could be used in prac-tical Information System Engineering projects. Also, it fails to discover cycles and redundancies in long sequences of roles (relationships) comprising loops 0. These constraints are captured in xUML (extended UML) methodology 0. In xUML, the stereotypes are proposed well suited for modelling constraints during development of Information Systems but there are lacking some kinds of constraints on attributes that are practised in EER, ORM and other methods. So it is advisable to unify constraints from different methods to obtain the best expressiveness.
In contrast to ORM, UML is well supported by many CASE tools and widely accepted as standard modelling language, having possibility to describe constraints formally in conceptual language (OCL 0, 0). Because UML is easy extendable, it is possible to extend UML model with stereotypes for visual modelling of whatever constraints that may be defined in other models. It enables transformation of constraints to software code or DBMS functionalities like check functions, triggers or stored procedures. Unfortunately, CASE tools for automatic transforma-tion from OCL to SQL and even OCL parsers are still under development or in early release phases (e.g. 0, the most promising one), so they are still unacceptable for wide use in practical projects.
3. Stereotypes for modelling of integrity constraints
There are alternative options for representation of constraints using UML: natural language, stereotypes and OCL expressions. Stereotypes are useful as pat-terns not only for discovering constraints, but also for succeeding generation of implementation code, as part of stereotypes directly map to functionality of data-base, avoiding dealing with complicated expressions. Notation for stereotypes in UML models (part of them are extensions to standard UML) is presented in the next sections, where some of them are illustrated by examples.