Mike Ault Naming Conventions White Paper

Mike Ault White paper

White Paper

WHITE PAPER PAGE 2

COPYRIGHT © 2002 ROBO BOOKS. ALL RIGHTS RESERVED.

NoticeWhile ROBO Books makes every effort to ensure the information presented in this white paper is accurate and without error, ROBO Books, its authors and its affiliates takes no responsibility for the use of the information, tips, techniques or technologies contained in this white paper. The user of this white paper is solely responsible for the consequences of the utilization of the information, tips, techniques or technologies reported herein.

Change HistoryRelease Date Description By1.0 8/2/2002 Initial release in ROBO Books format Michael R. Ault

WHITE PAPER PAGE 3


Table Of Contents

Notice..................................................................................................................................2

Change History.............................................................................................................................2

Table Of Contents..............................................................................................................3

Introduction........................................................................................................................4

Use of Standard Abbreviations.........................................................................................4

Databases...........................................................................................................................5

Tablespaces........................................................................................................................5

Tables..................................................................................................................................7

Columns..............................................................................................................................7

Constraints.........................................................................................................................8

Indexes................................................................................................................................9

Views.................................................................................................................................10

Redo Logs.........................................................................................................................10

Sequences........................................................................................................................10

Oracle8 Types...................................................................................................................11

Summary............................................................................................................................11

WHITE PAPER PAGE 4


WHITE PAPER

Introduction

When designing a database it is imperative that a naming standard be developed. The naming standard should address all levels of the process, from the database itself down to constraints on individual columns. A naming standard provides a common reference point for developers, and users, to use to obtain information on objects within the database and avoids latter confusion over what the developer or designer was trying to accomplish with the names given to database objects.

Naming conventions need to be applied across an entire enterprise model. This universal application of the standards prevents duplicate names and the ensuing confusion that may cause.

Use of Standard Abbreviations

A set of standard abbreviations should be developed that is provided to all developers and designers. This list of abbreviations should also include common synonyms, and provide definitions for any acronyms in common use in the company. This list should be a living document with periodic reviews to keep it current. If possible it should be an online reference that is readily available to everyone using the system.

Examples of Abbreviations:

Word Standard Abbreviation Activity ACTVY Action ACTN BreakOut BRKOT . . . . . . Zerox ZX

The standard abbreviation should be used for table, column and constraint naming.

Examples of a Synonym List:

Word Possible Synonyms Dog Canine, mutt Cat Feline Automobile Car

The word listed in the synonym list as the main word should be the one you want them to use.

Examples of an Acronym List:

Acronym Meaning USA United States of America ATM Asynchronous Transaction Methodology INS Inertial Navigation System

WHITE PAPER PAGE 5


WHITE PAPER

UFO Unidentified Flying Object

The acronym list should contain all of the acronyms commonly used in your business. These acronyms can be used for table and column names. A defined list prevents confusion such as ATM meaning Automated Teller Machine to one developer and Asynchronous Transaction Methodology to another.

In conclusion, when developing a database the first step should be to gather a comprehensive set of standard abbreviations, synonyms and acronyms for your company or group. This collection of data should be distributed to the entire development team and its use strictly enforced. Any new abbreviations should be added as should new synonyms or acronyms.

Databases

The database name should be meaningful and convey information. For example, suppose you are creating a database that acts as a Procurement Information Tracking System. This name is a bit long for a database name so we reduce it to an acronym, PITS. This acronym will be in our allowed acronym list. Next, we would like to know what database this application is written in, our approved abbreviation for Oracle is OR. It would also be nice to know if a database is used for development (D), testing (T) or Production (P) work. Finally, we may have multiple databases so let's put a numeric identifier that corresponds to the order in which this database was created. Our instance name becomes:

ORPITSD1 for our first development instance, ORPITST1 for our first training instance and ORPITSP1 for your first production instance and so on. A simple glance at the instance name now tells us the database the system was developed in, the application it is applied to, whether this is a development, test or production instance and a relative idea of when this database was created (first, second, third, etc.).

Oracle databases are limited to eight (8) characters for their name.

Names such as TEST, DEV and PROD should be avoided unless this is a very small development effort.

For parallel or shared instances, it is suggested a non-numeric be used in the name to denote this, so for two parallel PITS test instances the names would be: ORPITSTAORPITSTB

If this or a similar convention is used, the site specific convention document should state this relationship.

Tablespaces

Tablespaces should be named according function. In cases where multiple databases share the same directory for file storage the instance name should be included in the tablespace name. Generally speaking the file extension should be uniform for all database tablespace files. Usually the extension is either “.dbf” or “.dat” depending on your operation system. Each file in a tablespace should have a sequential number that relates to when it was created (1 for the first file, 2 for the next and so forth).

A database will have three types of tables, dynamic, static and temporary. It is suggested that the tablespaces be created using “dyn”, “stat” and “tmp” as a part of their name if the tables are partitioned in this manner. Using our database example name this would generate the following datafiles for table storage:

WHITE PAPER PAGE 6


WHITE PAPER

ORPITST1_DATA_DYN_1.dbf For dynamic, growing tablesORPITST1_DATA_STAT_1.dbf For static, configuration tablesORPITST1_DATA_TMP_1.dbf For temporary or report tables

Indexes should be placed in their own tablespaces, following the above convention:

ORPITST1_INDX_DYN_1.dbf For dynamic, growing tables indexesORPITST1_INDX_STAT_1.dbf For static, configuration tables indexesORPITST1_INDX_TMP_1.dbf For temporary or report tables indexes

Rollback segments should be placed in their own tablespace which should be named accordingly:

ORPITST1_RBKS_1.dbf

If a large rollback segment is required, place it in its own tablespace and name it accordingly:

ORPITST1_LRG_RBK_1.dbf

There are certain base tablespaces that are a requirement in any environment. These are the SYSTEM and TEMPORARY tablespaces:

ORPITST1_SYSTEM_1.dbfORPITST1_TMP_1.dbf

If a table is large enough to require its own tablespace (or an index) then name the tablespace accordingly. For example, if we are the federal government, our VENDORS table may be several hundred megabytes in size and require being spread across several tablespaces on several drives:

ORPITST1_VENDOR_1.dbf First partitionORPITST1_VENDOR_2.dbf Second partition...ORPITST1_VENDOR_n.dbf Last partition

And for the tables index:

ORPITST1_VENDOR_I_1.dbf First partitionORPITST1_VENDOR_I_2.dbf Second partition...ORPITST1_VENDOR_I_n.dbf Last partition

This convention again tells you what instance the tablespace is for, the general or specific purpose and the number of the datafile for tablespaces with more than one file.

In Oracle8 and greater databases partitioned tables may be used. Partitioned tables should be stored in tablespace that are named for the partition they contain.

If your system limits the number of characters for a file name, the above standard can be shortened by removing the underscores, using standard abbreviations and, if you follow a directory naming convention that partitions the files for a specific database into their own subdirectories, the instance name. However, use as much space as you can to provide clear, meaningful tablespace datafile names.

WHITE PAPER PAGE 7


WHITE PAPER

Tables

Following the relational model, table names should always be a plural noun since they are collections of entities (it logically follows that entity names should be singular in data models). Names should be as short as possible, usually equal to or less than eight (8) characters. This length restriction to eight characters is important since for column foreign key definitions and constraint naming the table name is used in conjunction with column names.

For example, the table used to track ACCOUNTS PAYABLE in the PITS application would be:

ACCT_PAY

assuming the standard abbreviation for ACCOUNT is ACCT and PAYABLE is PAY.

Wherever possible abbreviations and acronyms should be used to shorten the table name. The TAB_COMMENTS and TAB_COL_COMMENTS tables can be used to store a more detailed name which can be used in a simple help stored procedure to provide detailed information on the table and its columns.

The importance of short table names cannot be stressed enough. However, using codes like A1, B1, Z28 for your tables is also to be avoided. Short meaningful names are the best.

A specialized type of table is the intersection table. An intersection table allows resolution of many-to-many and recursive relationships. Let's say we have a many-to-many relationship between the PARTS table and the VENDORS table (VENDS for short). The resolving intersection table should be named:

VENDS_PARTS (assuming the VENDORS table is the driving table for the relationship).

In Oracle8 and greater versions tables may be partitioned. Table partitions should contain the table name and an indication of which partition the partition is, for example the first monthly partition would contain MON1 as a part of its name while the first quarterly partition would contain the year and quarter 99Q1.

Columns

Column names should be as short and as meaningful as possible. The requirement that the column names be short is driven by the fact that they are used along with the table names for constraint and index naming. The column should be named according to abbreviation and acronym standards. You may also strip vowels out of names to shorten them as required. However, each new abbreviation should be entered into the list so that it can be used across the application development effort. The entity VENDOR has the following attributes:

VENDOR

VENDOR CODE The primary identifierPRODUCT CODE Must have at least one codeDESCRIPTION OF SERVICES An optional description field

The standard abbreviation list has the following pertinent entries:

Name Abbreviation VENDOR VND

WHITE PAPER PAGE 8


WHITE PAPER

VENDORS VNDS PRODUCT PRD CODE CD DESCRIPTION DSC SERVICES SVC

So the table definition would be:

Table: VNDS

VNDS_CD NUMBER NOT NULLVNDS_PRD_CD VARCHAR2(64) NOT NULLVNDS_DSC_SVC VARCHAR2(200)

The primary key would be:

PK_VNDS

A lookup index on the Product code would be:

LI_VNDS_PRD_CD_1

Our examples illustrate the importance of short, meaningful names for columns and tables.

Constraints

There are five types of constraints in an Oracle database these are:

Primary KeyForeign KeyUnique ValueCheck ValueDefault Value

Constraints should be named by function. For primary and foreign key constraints the constraints should be named the same as their supporting indexes.

For example, for a primary key constraint on the ACCT_PAY table:

PK_ACCT_PAY or P_ACCT_PAY or ACCT_PAY_PK, etc.

For the unique value on the vendor code in the ACCT_PAY table the name could be:

UV_ACCT_PAY_VENDCD -- or -- UV_ACCT_PAY_1 (if it is the first unique value) -- or -- ACCT_PAY_VENDCD_U (The supporting index would be named the same)

Within the 32 character limit imposed by Oracle this name can be as wordy as you wish.

For a foreign key constraint, the constraint indicator, the constraint table and the foreign table should be included in the name, so for the foreign key to the VEND table from the ACCT_PAY table the constraint would be:

WHITE PAPER PAGE 9


WHITE PAPER

FK_ACCT_PAY_VEND --or-- ACCT_PAY_VEND_FK

It may not always be possible to include all the column names in a foreign key name. If this is this case you can make it just a numeric reference or describe the situation:

FK_ACCT_PAY_8COL_VEND --or-- FK_ACCT_PAY_1

For other types of constraint use a simple type indicator such as CK for check type constraints (such as NOT NULL constraints) and DV for default value. Include the table name and the column name. So for a NOT NULL on the VNDCD column:

CK_ACCT_PAY_VNDCD

You may also use a NN for NOT NULL instead of CK and reserve CK for special check constraints.

Indexes

Index names should reflect the table they belong to, their function and any other important data in their name. There are four types of indexes in most applications, these are:

Primary key IndexUnique IndexForeign Key IndexLookup Index

Assign a single or double digit abbreviation that reflects these types:

Index Type Double Digit Code Single Digit Code Primary key Index PK P Unique Index UI U Foreign Key Index FK F Lookup Index LI L

This single or double digit code should either come before or after the rest of the name. Next, the table name should be included, for a primary, unique or lookup index this may be all that is required. If there is more than one unique or lookup index, a sequence indicator or column name may also be included. For example, for a primary key on the ACCT_PAY table:

PK_ACCT_PAY or P_ACCT_PAY or ACCT_PAY_PK, etc.

For the lookup index on the vendor code in the ACCT_PAY table could be:

LI_ACCT_PAY_VENDCD -- or -- LI_ACCT_PAY_1 (if it is the first lookup index) -- or -- ACCT_PAY_VENDCD_L

Within the 32 character limit imposed by Oracle this name can be as wordy as you wish.

For a foreign key index the index indicator, the index table and the foreign table should be included in the name, so for the foreign key to the VEND table from the ACCT_PAY table the index would be:

FK_ACCT_PAY_VEND --or-- ACCT_PAY_VEND_FK

WHITE PAPER PAGE 10


WHITE PAPER

We recommend naming the indexes with the index type indicator first so you can tell with a quick glance at an object list what are indexes and what are tables; however, this is a matter of personal preference.

Views

View names should include a VW to indicate they are a view (a synonym may be created to hide this fact from the users) followed by the table name or names that the view includes (if possible).

For example, if we have view that includes the ACCT_PAY and VEND tables it would be called:

VW_ACCT_PAY_VEND and may have a synonym of CREDITORS.

Another method is to name the view according to function so the above view name would be VW_CREDITORS with a synonym of CREDITORS.

Redo Logs

Redo logs should be named such that they contain thread, group and member information. The instance name can also be included on systems where multiple databases reside. It is suggested that the word “LOG” be included either in the name or the file extension:

For a two thread, three group, two member per group database:

ORPITST1_LOG11A.dbf -- or -- ORPITST1_11A.log For thread 1, group 1 member 1ORPITST1_LOG11B.dbf -- or -- ORPITST1_11B.log For thread 1, group 1 member 2ORPITST1_LOG12A.dbf -- or -- ORPITST1_12A.log For thread 1, group 2 member 1...ORPITST1_LOG23B.dbf -- or -- ORPITST1_23B.log For thread 2, group 3 member 2

Note: Since multi-threaded logs are usually only used for multi-instance databases, there may be two instances (or more) involved in a multithreaded redo log naming standard. For grouped instances, ensure this is reflected in the instance naming, such as by using A, B in place of numbering of the instances. This should be defined in the site naming conventions.

Sequences

Sequences are used for derived primary keys, or for other situations where a number is required in the database. Sequences should be named for the table and column they are used for. The SEQ indicator should be either the last or first part of the name to differentiate sequences from other database objects. A sequence used to derive the vendor code for the vendor table would be named:

VNDS_VNDCD_SEQ -- or --- SEQ_VNDS_VNDCD

Sometimes sequences may be shared for a group of tables. In this case the tables should form a section of the database such as the VENDOR section or the PRODUCT section. It is not advisable to have a

WHITE PAPER PAGE 11


WHITE PAPER

single sequence used by an entire application. In the above situation name the sequence for the section in which it is used:

PRODUCT_SEQ -- or -- VENDOR_SEQ

Oracle8 Types

Generally, types should follow the previously noted naming conventions. However, there are some basics constructs in types that require new rules.

1. All defined TYPES end in “_t”2. All VARRAYs constructed from types or standard datatypes end in “_v” (use “_vw” for views)3. All NESTED TABLES constructed from types or standard datatypes end in “_list”.4. When used in a DDL statement native datatypes are capitalized while user defined types are

lowercase.5. The entities are singular while the tables or objects that they become are plural or are a plural or

neutral form.6. All REF columns end in “_r”.7. All Object ID indexes (OID) have the prefix “OID_” followed by the table name.

Summary

The importance of naming conventions cannot be stressed enough. The database needs to be designed using standard names, abbreviations and synonyms. If naming conventions aren’t created and applied consistently a database quickly becomes unmanageable.

WHITE PAPER PAGE 12


Mike Ault Naming Conventions White Paper

Documents

Transcript of Mike Ault Naming Conventions White Paper