Data, and the assets surrounding the lifecycle of that data, are valuable assets for your organization.
As valuable assets, they should be created, evolved, managed, and eventually retired appropriately.
Or at least they should be.
Configuration management is a critical aspect of treating database assets like true assets.
This article overviews the technique of database configuration management.
This article is organized into the following topics:
- Why database configuration management?
- The process of database configuration management
- What database assets should be put under configuration management control?
- Database configuration management in context
- Related resources
Let's begin with a few definitions:
- Configuration management (CM). A systems engineering process for establishing and maintaining consistency of an asset's performance, functional and physical attributes, requirements, design, and operational information throughout its life. The aim is to ensure that engineers may successfully produce systems in a desired and consistent state.
- Database. A database is any place where data is stored, also known as a data source. This could be something as simple as a file or something as complex as a database management system (DBMS). Databases may have both schema and state.
- Configuration item (CI). An element, or unit, that is put under configuration management control. In the case of a database, this includes, but is not limited to, models, database build scripts, test data, database test scripts, source code for database functionality such as stored procedures, and reference data. CIs are also referred to as assets.
- Database asset. A database asset is anything that is required to create or operate a database.
- Configuration information. Information captured about an asset within your configuration management system. This may include, but is not limited to, a description of the asset, change history of the asset, status, where the asset is used, and potential expiry/decommissioning information.
- Database configuration management (CDM). As the name implies, DCM is the database version of CM.
2. Why Database Configuration Management?
There are several reasons why you want to put your database assets under configuration management control:
- Integrity. All work products should be stored in a versioned repository so that you know what assets are used to create the database and you have actual copies of them. This maintains the integrity of the database definition and all supporting work products as it evolves.
- Safety. You want to be able to restore your database to a known state. Not only does this include restoring the database itself, but all the accompanying assets associated with that version of the database.
- Evolution. Facilitates change in a controlled fashion, enabling you to safely evolve your database.
- History. All revisions are kept, including indications of who made the changes and hopefully why they made them.
3. The Process of Database Configuration Management
Figure 1 summarizes the primary activities of configuration management.
Database configuration management is the CM of database assets.
Note that a database asset may be comprise several component assets,
which in turn may be composed of further sub assets.
For example, the database model may be composed of a logical and physical model.
The physical model in turn may be composed of a schema definition and source code
files for each stored procedure/function within the database.
Figure 1. Configuration management activities.
There are four primary activities of DCM:
- Asset change management. Control changes to a database asset and its configuration information. This includes the ability to check database assets in, check database assets out, and track any changes to database assets.
- Configuration identification. Define a database asset and its configuration information. Configuration information describes all of the aspects of an asset. This may include, but not be limited to, a description, change history, links to related (sub) assets, expiration date, references to where the asset is used, and more.
- Configuration status accounting. Provide status and information about an asset, including its configuration information. This should include the ability to provide the status of an asset at any given point in time, not just the current state.
- Configuration audit. Verify the consistency of an asset's configuration information.
4. Potential Database Assets to Put Under Configuration Management Control
To enable evolutionary database
development you need to put the following items under configuration management
- Data definition language (DDL) scripts to create the database schema
- Data load/extract scripts
- Data model files
- Object/relational mapping meta data
- Reference data
- Stored procedure and trigger definitions
- View definitions
- Referential integrity constraints
- Other database objects like sequences, indexes etc.
- Test data
- Test data generation scripts
- Test scripts
5. Database Configuration Management in Context
The following table summarizes the trade-offs associated with
database configuration management and provides advice for when (not) to adopt it.
- Enables you to manage versions of databases, and the assets they are comprised of, across environments.
- Enables you to rollback portions of a database to previous versions.
- Enables you to modify work products in parallel and then merge the work.
- Makes it easier to identify the source of defects injected due to the change history maintained about assets.
- Requires database developers to be trained in CM-related skills.
- May require new tooling, in particular the CM system itself.
When to Adopt This Practice
- For the development of any database that is expected to be evolved over time, particularly when this will occur over a long period of time, or by different people.
- It is mandatory in regulatory environments that explicitly call out CM control of your assets.
6. Related Resources