 |
Over time, it may become necessary to change the data model, based on
changes in requirements, problems that occur, or new functionality that
is added. Data model changes generally fall into one of the following
types:
- Modification of existing attributes
or properties in a specific category or class: These
are considered high impact changes. If the changed category is
used by the user and contains data, that data may have to be
recreated, depending on the actual changes made to the
attribute(s). Examples of this kind of change are: changing the
label of a property, changing the mandatory status of a
property, or changing a normal property to a primary key.
- Creating or modifying forms for a
specific category or class: These are considered high impact
changes. If a form is modified during or after deployment, as
part of customization, then a change to the out-of-the-box
version of the same form will create conflict and have to be
resolved manually, to retain the customization.
- Adding a new attribute or property
to a specific category or class: These are considered low
impact, since they do not impact the existing setup.
- Adding a new category or class:
These are considered low impact, since they do not impact the
existing setup.
All data model changes made during any main cycle, for example a new
release, a service
pack, etc. are provided as CES DBLoad files. These changes are distributed
with clear demarcation in the package. For example, R1n SPx changes are
available in <OS_a>/resources/sdm/sdmdb/dbUpdate/R1nSPx, where n is the
last number on the release (R17, R18, etc) and x is the number of the
service pack (SP1, SP2, etc.).
This process can be carried out manually, but it is difficult and
time consuming. The difficulties associated with manual updating
include:
- setting up DBLoad and running the scripts manually
- configuring the DBLoad utility is not easy
- there is no information in the database to determine which
data model changes are applied
- messages displayed while running the DBLoad utility cannot
be interpreted
- trouble shooting this process is difficult
To make this process easier, an automated method is provided as a
stand-alone tool, CESDBUpdate. This tool does the following:
- Determines the existing level of the CES database
- Executes the scripts to update the CES database to the
requested level
- Interprets messages generated during script execution and
reports meaningful information to the user.
-
-
-
|