Page Comparison

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.

CI Naming Convention

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}

{modifier}

{-dev}

{fqdn}

Notes:

• This convention applies to all database types including SQL Server, Oracle, MySQL, Mongo, and others.
• 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.

Examples

The following are examples of CI names 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

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

Suggested Dependencies

The following relationship types should be are typical relationships used when defining dependencies for databases:

Notes:

1. 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.