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} | 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} | 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} | 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:
- 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.
| 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. |
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
| Info | ||
|---|---|---|
| ||
Additions and changes to the CMDB should be made carefully and at the appropriate time. Be sure to review How to Maintain the CMDB Quality and Data Integrity before making any changes. This article explains when and how CIs are maintained and who should be maintaining them. If you have any questions about maintaining CIs then contact the ServiceNow Support Team for more information. |
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. | If ServiceNow will be used to track incidents, changes, or task assignments while the database is being prepared then a CI will be required. Otherwise, a CI is not required 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. | A Configuration Item Management Form is submitted by a member of the team supporting the database and the new CI will be added to the CMDB by the CMDB Administration Team. |
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. | Ongoing adjustments to the Status, State, and other fields in the CI record are made as needed by a member of the team supporting the database. |
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 a member of the team supporting the database to reflect the fact that it is no longer operational and has been retired. At the same time, the database name in the CI is modified to include a prefix of RETIRED to make it obvious in listings and searches that it is no longer in use. 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 software and any activity documented by incidents and change requests. |
Suggested Relationships
When mapping dependencies and relationships, the following are typical connections to other CI classes used by databases:
Relationship | Dependent Class |
|---|---|
Uses | Database1 |
Depends on | Application |
| Depends on | Business Service |
Runs on | Server1 |
| 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 | ||||||
|---|---|---|---|---|---|---|
|