In a production environment, it is likely that you will need to migrate data from your existing system(s) to your Cúram database.
The specification of such a migration exercise is outside the scope of this document since it requires in-depth knowledge of the following:
- Cúram Reference Model, together with any customizations you may have made
- Structure and integrity of your existing data
- Any requirements you may have for the ongoing synchronization of data between Cúram and your other systems
- Any existing migration procedures you may have
Notwithstanding the above, the following suggestions are worth making here:
- Sample initial data that is required to start the Cúram online server is provided. This initial data contains such items as an administrative user (admin). The initial data may be customized before loading into your database, or may be customized through the application itself (before "going live").
- Demonstration data is provided and it is suggested that you do not load this data into your production database.
- You may wish to pre-sort your data in line with your data clustering strategy.
- The Cúram Reference Model includes database foreign key constraints which help maintain the integrity of the Cúram data. If these constraints are applied before loading your migrated data, then constraint violations may occur if your data is not loaded in "parent-child" order1 ; therefore, it is suggested that foreign key constraints are applied after your migrated data has been loaded2 . Any constraint that is rejected by the database will indicate an integrity problem in your migrated data.
- The Cúram Reference Model includes indexes to support all SQL queries used from within the Cúram Server Application. You may wish to drop some of these indexes in order to improve the performance of database write operations, at the expense of degrading the performance of some rarely-used queries. This exercise can only be undertaken once you have an understanding of which transactions in the application will be used online heavily at your installation and which will be used rarely online or solely in batch.
1 Often in a relational database a "parent" entity is associated with zero, one or more "child" entities; each of these child entities bears the key of its parent, and as such, the parent must be created first so that its key is available (in order to set the parent's key on the child) when the child is subsequently stored.
2 It is recommended that you create foreign key constraints to identify integrity problems in your converted data, and then (once any problems have been resolved) drop these constraints as they are not supported for production databases.