BRIM™ Class Diagram Syntax: UML Repository Objects
This section
describes the objects in the BRIM™ Unified
Modeling Language (UML) Repository.
A
rule in BRIM™ includes all
of the business rules that are in effect at any point in time.
A rule is a
collection of business rules corresponding to a database in Oracle. Only one rule can be active at a time. You
can have multiple rules for the purpose of versioning, rules that in
development, etc.
The related BRIM™ methods to manipulate rules are:
Uml_ddl.CreateRule
Uml_ddl.DeleteRule
Uml_ddl.InstantiateRule
The related BRIM™ methods to obtain information about rules are:
Uml_rep.IsRule
Uml_rep.GetRuleId
Uml_rep.GetGeneralizationStructure
Uml_rep.IsRuleInstantiated
The properties of
rules are as follows:
·
Rule Name
(Name_TX)
This
property stores the name of the rule.
Rule Name is unique in the system.
·
Instantiated
This
property indicates whether or not the rule is instantiated. When a rule is
instantiated, its associated database is generated.
·
Description
(Descr_TX)
A
text description of the rule.
·
Active
(Activ_YN)
Logical
deletion of the rule. Only active rules can be instantiated. Most lists of
rules will only show active rules.
Implementation Notes
When a rule is
instantiated, all changes made to the repository object in that rule are first
validated to see if the existing objects violate the change request.
Example:
Let the class
“Person” be a concrete class in an instantiated rule and have an attribute
called “LastName.” Further assume that LastName has the domain Str255 that it
is a simple domain of type Varchar2, length 255. Assume Str10 is a simple
domain of type Varchar2 and length 10. An attempt to change the domain of
attribute LastName from Str255 to Str10 will succeed only if there are no
persons with a last name longer than 10.
A class is a basic
UML class. It roughly corresponds to an
entity in relational database. Classes are physicalized into tables and views
(see the Table View generator document for more details.
The related BRIM™ methods to manipulate classes are as follows:
The properties of
classes are as follows:
Class
Code
This
property stores the code of the class and will be the name of the generated
view. It must be less than 25 characters and be a valid Oracle table name.
Class
Name
This
property stores the name of the class and is used in UI applications.
Description
(Descr_TX)
A
description of the class
Note
(Note_TX)
A
designer note about the class.
An association class arises from a
many-to-many association.
For
example, an organization can be associated with different currencies, and the
roles of each currency can be different.
This situation can be represented correctly only through an association
class as shown in Figure 1:
Figure
1: Association Class Example
At the physical level, association class will store its own
attributes and IDs of classes from both sides.
In this example, Organization Currency will store currency_id and
organization_id.
The main difference between an association class and a
regular class is that an association class does not have any meaning without
the classes in the basic association.
The association and the association class object are created
and deleted at the same time.
Association classes can have attributes, and they have all the features
of a regular class.
Related BRIM™ methods:
Manipulations:
uml_ddl.uml_ddl.CreateAssociationClass
uml_ddl.ConnectClass
uml_ddl.DisconnectClass
Information:
uml_rep.IsAssociationClass
uml_rep.HasClass
Primary keys are a
traditional relational database concept not normally used in the context of
object-oriented design. However, we have found that having a mechanism for
uniquely identifying an object in the table other than its OID to be a useful
and timesaving concept. Also, specifying primary keys for classes adds rigor to
the design and helps decrease modeling errors. Although not essential to making
the system function, we believe that primary keys should be specified for each
class in the system.
Attributes and/or
object associations may be part of a primary key specification. Primary keys
may be made up of multiples of these attribute/object association components.
Primary key
constraints are checked:
1.
On creation of
objects and every time any of the PK components for that object are updated.
2.
To ensure that
only one object in the class may have a particular set of PK component values.
The only exception is if the PK constraint has been relaxed through a history
specification.
When a PK constraint
fails, an error message should be generated in the form “Primary Key constraint
on class X was violated. Duplicate record found” or “PK constraint on class X
violated component. Component name may not be null.”
Primary keys are
stored in a PK_TX column within the UML_RULE_CLASS table. The syntax for this
is as shown here:
|
Primary Key Type |
Syntax |
|
Attribute |
ATTRIBUTE-name
of attribute |
|
Association |
ASSOCIATION-association_id |
|
Generalization |
SUPERCLASS |
Primary key
components are separated by a comma. Logically, the order of the PK components
is irrelevant. However, because we will be physically instantiating tables
based on the classes, we will form the PK constraint in the same way that
Oracle does, i.e. in the order of its components. This means that searches
based on a subset of the PK components will only take advantage of the index if
the search is based on the first few PK components. If the first PK component
is not in the search criteria, the index will not be used and a full table scan
may be required.
The actual physical
implementation of primary keys uses a PK table behind the scenes with three
columns: Class Name, OID, and PK Value. For PK Value, a text-based
concatenation of the PK values is stored. When records are being inserted into
the generic physical tables, a record is also placed into this centralized PK
table. This allows for rapid and consistent validation of PK values without
requiring complex searches through generic value tables.
Example:
ATTRIBUTE-DEPTNO,ASSOCIATION-123,SUPERCLASS
The abstract property
indicates whether a class is abstract or concrete. (See section 5 about Generalization).
In particular,
concrete classes are characterized as follows:
·
Have
instances,
·
Have their own
attributes, either logical or physical attributes, and
·
Attribute
values belong to the instances of the class
In contrast, abstract
classes are characterized as follows:
·
Cannot
be instantiated, that is, there are no objects of that class in the database,
·
Can have only logical
attributes, and
·
Values of the
attributes physically belong to instances of concrete sub classes
Related BRIM™ Methods
Manipulation
uml_ddl.CreateAbstractClass
uml_ddl.MakeAbstractClass
uml_ddl.MakeConcreteClass
Information
Uml_rep.IsAbstract
Uml_rep.IsAbstractGener
History is specified
by applying the keyword “History” to the class. Note that history can also be
applied to an association, meaning that it is being applied to the automatically
generated association table. With simple history, two additional attributes are
automatically added: StartDate and EndDate.
StartDate and EndDate
are added as attributes to the class.
NOTE: StartDate and
EndDate are not specified in the UML diagrams. By default, start dates and end
dates allow any valid date except where they violate the history constraints as
described below. Both are optional.
Neither the start
date nor the end date may be after the current system date. If you want objects
with future effective dates, you should add additional attributes to the class
for this purpose. The History keyword has a very precise meaning and does not
support this functionality.
If StartDate and
EndDate are both not null, StartDate must be less than EndDate. Records may
exist without Start Date when the start date is indeterminate. This is often
the case for data migrations. However, you cannot have a logically deleted
record without an end date since deleted records are detected by a non-null end
date.
By placing a
“History” keyword on a class, when that class is created in the repository, a
Start Date and End Date will automatically be added to the class.
When you create an
object with history, a start date of sysdate is assigned to the start date
attribute by default. StartDate is an optional parameter in the Create Object
command and can be overridden by passing a start date parameter at object
creation.
StartDate behaves
like any other attribute and can be modified or made null using a Set Attribute
command.
Applying a keyword of
“History” to a class does not affect the behavior of its primary key. This is
equivalent to setting an active flag on a relational database record. The
record still exists. If an Employee with an EmpID as a primary key exists and
history is associated with the Employee class, when the Employee is deleted,
you cannot insert a new employee with the same ID.
To remove the
Employee record from the database, use the overloaded DELETE-OBJECT function.
You can either pass the delete date or the character string “remove” in the
position of the optional parameter. If you pass “remove,” the record will be
removed from the database.
For manipulation
Uml_ddl.CreateHistory,
Uml_ddl.DeleteHistory
For Information:
Uml_rep.GetHistoryType
History has an impact
on the cardinality of rule associations. In particular, sometimes you want the
association to be considered part of the object and the history class. At other
times, you do not. In Figure 2 shown below, there are sales attached to
customers and customers are placed together in customer groups with no more
than ten customers in each group.
Figure 2: History on Associations
Example
If the customer is no
longer in business and needs to be deleted from the system, in the case of a
sale, we do not want the deletion of the customer to orphan the sales records.
Neither do we want to inactivate the association of the sale record since that
would allow the sale objects to be attached to an additional customer.
However, in the
customer group, the opposite situation exists. When the individual customer is
inactivated or deleted, that customer’s position in the customer group should
be available to another customer. Sometimes the deletion of the object should
also invalidate or delete its associations, but not in every case.
The way in which the
engine works, associations are stored independently from the objects that they
attach. Cardinality rules are validated by counting valid records in the
association table. Therefore, in the implementation of history, when a command
is received to delete a history object, this triggers no validation of any
cardinality rules since the engine cannot determine whether cardinality
restrictions should or should not be observed in any given situation.
When deleting history
objects, the applications must determine (on a case by case basis) whether a
particular association should be deleted, invalidated or ignored. The
cardinality rules will be enforced when any attempt is made to invalidate or
delete an existing association.
Complex history
involves the tracking of history on the record and allows duplicate primary key
values in the class, and is called PkHistory.
Primary key history
behaves in a similar way to regular history since start date and end date can
be added. The commands used are the same and behave in the same way with the
following exceptions:
·
When you execute
a Delete command, the associated record is removed from the PK table enabling
the primary key of the class to be reused. Because the primary key is not
really the PK (in the actual physical table) the primary key will be the
logical primary key plus the OID.
·
If you have
multiple records with the same primary key, there is a further stipulation that
the start dates and end dates may not overlap as illustrated in the following
examples.
The following are
examples of successful and unsuccessful insertions to an organization class,
(PK = OrgID)
|
|
Original |
New |
|
|
|
|
Object |
Object |
|
|
|
OrgID |
100 |
100 |
|
|
|
StartDate |
1/Jan/2000 |
1/Jan/2001 |
Succeed |
|
|
EndDate |
1/Jan/2001 |
|
|
|
|
|
|
|
|
|
|
OrgID |
100 |
100 |
|
|
|
StartDate |
Null |
1/Jan/2001 |
Succeed |
|
|
EndDate |
1/Jan/2001 |
|
|
|
|
|
|
|
|
|
|
OrgID |
100 |
100 |
|
|
|
StartDate |
1/Jan/2000 |
1/Jan/2001 |
Fail |
|
|
EndDate |
Null |
Null |
|
|
|
|
|
|
|
|
|
OrgID |
100 |
100 |
|
|
|
StartDate |
1/Jan/2000 |
1/Feb/2000 |
Fail |
|
|
EndDate |
1/Jan/2001 |
Null |
|
|
Effectively, we are
relaxing the PK constraint so that the class may have duplicate primary keys as
long as the StartDate and EndDate do not overlap. This constraint must be
checked every time any primary key columns are changed, when the StartDate or
EndDate attributes are set and whenever an object is created.
The StartDate and
EndDate are implemented in the PARTY_VAL table. The Activ_YN is in the
generated class views.
For manipulation:
Uml_ddl.CreateHistory,
Uml_ddl.DeleteHistory
For Information:
Uml_rep.GetHistoryType(ClassCode)
The audit trail
property allows the user to keep an audit trail of a particular class, that is,
all of the values that a particular class receives over time are stored. This can be useful for a variety of reasons,
including retaining information for auditing purposes or identifying the source
of error in data.
There are
four different types of audit events or changes that the Engine can track, and
they can be grouped into the following two categories:
1.
Object-level
events belong to the objects:
a.
Create
event
b.
Delete
event
c.
Reactivate
event
2.
Value-level events belong to attributes or
associations of the object:
a.
Modify
event
If the
audit event type is modified, the UML Engine will store both old and new
values.
Schematically,
audit data is stored can be represented as shown in Figure 3:
Figure
3: Data Model for Audit Trail
Implementation Notes:
The class
must have no objects. Right now the DDL
command does not support starting an audit trail for instantiated classes.
Once the
audit trail is started the engine will create an audit object for each object
in the audited class and keep track of the changes applied to the object.
Related BRIM™ Methods:
BRIM™ Constants
Uml_system.AuditTrail
– keyword to define class to be audited
Uml_system.CreateAuditEvent
Uml_system.ModifyAuditEvent
constants for events
Uml_system.DeleteAuditEvent
Uml_system.ReactivateAuditEvent
Manipulation
Uml_ddl.StartAuditTrail
Uml_ddl.StopAuditTrail
Information
Uml_rep.HasAudit
The Class Out of
Engine keyword or property allows a class to be implemented outside of the UML
Engine. The UML Engine will not
recognize the objects in that class nor the associations of these objects. Consequently it is not responsible for
enforcing the business rules for that class and its associations.
Classes that are not in the UML E