A database is a collection of information that is organized so it can be easily accessed, managed, and updated. OIT provides a full range of database services from creating new databases to managing databases for clients across campus.
Because many OIT clients have their own naming standards for databases it is difficult to specify a standard that would meet the requirements of all clients. When a client has a specific database name they would like to use, that name should be used. When there is no such constraint, database names should follow the form of:
{app_name} {modifier} [-dev] @ {fqdn}Where:
{app_name} | The name of the application that will be the primary user of the database. |
|---|---|
{modifier} | Any modifier may be used to help clarify the purpose of the database. For example, a database used to contain purchase order information in an accounting application might be named "accounting_purch" |
{-dev} | A suffix used to indicate that the database is used for the development instance of an application. When an application has both a production and development instance, the development database name will be exactly the same as the production database name except the development database will include the "-dev" suffix. |
{fqdn} | This is the fully-qualified domain name for the server where the database is installed. The "@" sign between the database name and the FQDN is not optional. |
Notes:
- In all cases, symbols, integers, and upper and lower case alphabetic characters may be used in any combination that is compatible with the operating system supporting the database and the application that uses it.
- Elements of the database name (not including the "@" sign and FQDN may be separated from each other using a delimiter that is compatible with the database being used. Hyphens, underscores, and periods are the most commonly used delimiters.
- It is generally not necessary to include the abbreviation "db" (meaning "database") in a database name. It is redundant information and makes the name more complex.
- It is generally not necessary to include the type of database (oracle, sql, db2, etc.) in a database name. The users of the database will already know what kind of database they are working with and it makes the name more complex.
| Info | ||
|---|---|---|
| ||
When an database is retired, the database name must be modified to include a prefix of RETIRED to make it obvious in listings and searches that the database is no longer being used. |
Database CI Name Examples
The following are examples of CI names that have been standardized using the conventions described above.
using this standard:
- sams@novation-db.
- oit.uci.edu
- studentaffairs@orientation.
- uci.edu
- kraft-
- dev@drifter.
- uci.edu
- RETIRED - research.
- gd@performance.
- uci.edu
Typical Life Cycle for Databases
(base this on "CI Life Cycle Summary: Software or Intangible Assets" but without the SDLC parts.)
CI Maintenance
Owner | Create CI | Change CI | Decommission CI | Maintain Relationships | Comments |
|---|---|---|---|---|---|
|
|
|
|
|
Typical Relationships
The following relationships 
| Phase | CI Activity |
|---|---|
Phase 1:Database Developed or Acquired This phase covers the original requirements definition, design, and development (or purchase) of the database. With respect to database CIs, it does not matter whether the database is developed in-house or installed by a third party. This phase ends when the database is ready to be deployed into production. | No CI required. A CI does not need to be added to the CMDB until the database is ready for deployment. |
Phase 2: Database Tested & Deployed When the client determines that the database meets all the initial requirements and OIT determines that it is ready to begin production support of the database, the database is deployed into an appropriate environment. This phase ends when the database is ready to be used for its intended purpose. | Submit a ServiceNow Configuration Item Update Request and the new CI will be added by the CMDB Administration Team. Once the CI has been added to the CMDB, you can use the Status and State fields to indicate the installation status and operational state of the database. |
Phase 3: Database in Service & Maintained This phase represents the useful production life of the database. Throughout this phase, the database will undergo periodic maintenance, upgrades, failures, and fixes. At some point, the database will no longer be needed and plans need to be made to take it out of service. This phase ends when the database is no longer being used. | If a CI is in ServiceNow for the asset then Status, State, and other fields are maintained by the asset owner. If a CI has not yet been added, then submit a ServiceNow Configuration Item Update Request and the new CI will be added by the CMDB Administration Team. |
Phase 4: Database Retired When the application is no longer needed, either because it is being replaced by something newer or it no longer serves any useful function, it is retired. | The Status and State are updated by the database owner to reflect the fact that the database is no longer operational and has been retired. Under no circumstances should a CI ever be deleted from the CMDB. Deleting a CI record will make it impossible to trace the history of the database and any activity documented by incidents and change requests. When there is no longer a need for the database, the database name in the CI is modified to include a prefix of RETIRED to make it obvious in listings and searches that the database is no longer in use. |
Typical Dependencies
The following relationship types should be used when defining dependencies for databases:
Relationship | Dependent Class |
|---|---|
Uses | Database1 |
Depends on | Application |
| Depends on | Business Service |
Runs on | Server |
| Sends Data To | Application |
Receives data from | Application | Used by |
1 | |
| Hosted on | MySQL Instance |
| Hosted on | Microsoft SQL Server Instance |
| Hosted on | Oracle Database Instance |
Notes:
- Use the appropriate subclass. For example, if the database runs on a Linux Server then define a dependency to the appropriate physical or VM Server class and not the more generic Server class.
| Include Page | ||||
|---|---|---|---|---|
|
On this page...
| Table of Contents | ||||||
|---|---|---|---|---|---|---|
|